Time to give my POV here :).
----- Original Message -----
From: "Andy Grimm" <agrimm(a)gmail.com>
To: "java-devel" <java-devel(a)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(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/java-devel