[fedora-java] Fedora vs JPackage naming

Aleksandar Kurtakov akurtako at redhat.com
Fri Feb 17 08:01:50 UTC 2012


Time to give my POV here :).

----- Original Message -----
> From: "Andy Grimm" <agrimm at gmail.com>
> To: "java-devel" <java-devel at lists.fedoraproject.org>
> Sent: Thursday, February 16, 2012 9:21:02 PM
> Subject: [fedora-java] Fedora vs JPackage naming
> 
> After running into a few complicated naming situations, I decided it
> would be worthwhile to pose this question to the list.  For context,
> the current Fedora package naming guidelines say this:
> 
> "When naming a package, the name should match the upstream tarball or
> project name from which this software came. In some cases, this
> naming
> choice may be more complicated. If this package has been packaged by
> other distributions/packagers in the past, then you should try to
> match their name for consistency. In any case, try to use your best
> judgement, and other developers will help in the final decision."
> 
> In the java world, a few issues come into play.
> 
> 1) the history of jpackage naming, where a packages are often named
> according to the section of the apache project from which they came.

I would say keeping jpackage compatibility but if upstreams have moved/changed, the jpackage name is ambiguous nowadays or even there is a name that matches other things in fedora better we can live without this compatibility.

> 
> 2) the upstream tarball naming and jar file names, which typically
> lack the "ws-commons" prefix.

There are too many Java projects that have all 3 (project, tarball, jar) names differ or even worse jars from the same
tarball/projects use different name schemes. This is a case where I think we don't have better solution but to trust the 
packager and the reviewer working on the package to come with the best package name. I doubt anyone can come up with a policy 
that is less than stupid if the upstream project can not cope with that.

> 
> 3) the existing Fedora packages, where we have apache-commons-* ,
> xml-commons-*,  one ws-commons-* package, and one ws-* package.

I would say that these package names are because of legacy reasons.
WS/XML projects have sub-projects floating around in them and commons is just to common to mean something.
We can even use just codec/lang if we go on removing the unneeded parts. That's why we have always had them fully prefixed - jakarta-commons, apache-commons and etc. I don't see a good reason to change that. 

> 
> 4) apache's own naming in github is different from their svn naming
> (partly due to a lack of hierarchy):
> 
> https://github.com/apache/webservices-axiom
> 
> versus
> 
> http://svn.apache.org/viewvc/webservices/commons/tags/axiom/

As apache doesn't have official git repo probably we should not care about that until they come up with one.

> 
> 5) If we go with short names (to match the jar files), we have a
> greater risk of collision with other project names, e.g.,
> http://savannah.nongnu.org/projects/axiom
> 
> So I look at all of these conflicting possibilities, and I think we
> need to come to some consensus about what to do here.  I considered
> posting this to the packaging list, but I think it's a fairly
> java-centric problem at this point.  Feel free to report on that list
> if you believe it's appropriate, though.

My opinion is that we should try to match the artifactId in the maven case and if it looks ambiguous add the project name as we currently do.
I really trust packagers to make the right choice. Once there is an all Java land module system this things will settle down. I really encourage people
interested in this area to join the Jigsaw/Penrose projects and help people there to come up with a module system that will work for us. We don't have to think of package names and etc. because until there is a heavily used module system in the JVM we would never manage to have proper and sensible naming. Until then I don't see better choice than going on case by case. 

P.S. Every mass package rename with Jigsaw scheduled for Java 8 would do nothing more but enhance the mess.

Alex

> 
> (And if this topic has already been beaten to death, I apologize.  I
> couldn't find a documented resolution, though.)
> 
> Thanks.
> 
> --Andy
> --
> java-devel mailing list
> java-devel at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/java-devel


More information about the java-devel mailing list