On Thu, Feb 16, 2012 at 2:58 PM, David Walluck <david(a)zarb.org> wrote:
On 02/16/2012 02:21 PM, Andy Grimm wrote:
> 1) the history of jpackage naming, where a packages are often named
> according to the section of the apache project from which they came.
Some packages are also prefixed with `apache-'. Apache itself sometimes
does this upstream, but not usually. I don't agree with the blind prefix
and a I also never udnerstood why the commons projects weren't just
named starting with `commons-'.
Agreed, the use of "apache-commons-" as a standard is part of what
confuses me, as "commons-" is what would seem to match our standard
> 2) the upstream tarball naming and jar file names, which
typically
> lack the "ws-commons" prefix.
If neither the project documentation, scm, or artifact uses it, then
what is the justification for it? Probably, there is no good reason. I
mean, `ws' is clearly short for `webservices', but Apache itself can't
seem to decide here either.
I think the only reason (aside from "that's what JPackage called it")
is to differentiate it from another project which may have a similar
name (my axiom example). In the debian world, the lib*-java construct
for java library packages, while I find it a bit awkward, is
sufficient differentiate from an end-user app or library in another
language.
> 3) the existing Fedora packages, where we have apache-commons-*
,
> xml-commons-*, one ws-commons-* package, and one ws-* package.
To be fair, Apache does call it XML Commons upstream, at least in the
docs. But why is it not `apache-xml-commons'. This way we can make the
name even longer!
I recently worked on xml-commons-resolver. This seems to be the name in
the docs and specifically the name in the SCM. But, I'd really prefer
that it were named 'xml-resolver' as this is the artifact id (jar name)
upstream.
+1
Part of the problem is the horrible paractice of renaming a jar to
the
package name. To me, this is absolutely unacceptible. Everyone in the
Java world knows this artifact by a particular name and I don't think we
should be changing it. It confuses me greatly all the time. Where is
xml-resolver.jar? Oh wait, it is called xml-commons-resolver.jar? Only
in Fedora I guess...
+100 (though I'm quite annoyed by jar names which are too generic)
Again, Apache couldn't seem to make up their mind here, and I
believe it
has also been called resolver.jar, which is a very generic name. But,
let's not add to the confusion by adding yet another name.
> 4) apache's own naming in github is different from their svn naming
> (partly due to a lack of hierarchy):
And they have chanaged their own naming scheme in the past so this in
itself is not reliable at all (for example, `jakarta', and the previous
`ws' vs. `webservices' case).
> 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 feelings:
1.) We should not be including 'apache' in the name, unless it appears
upstream (for example, `apache-mime4j'). There may be legal
ramifications for using the org name (for example, 'mozilla-firefox' vs.
'firefox'). Using the org name to me implies that we are the org. This
is not right in my opinion.
The nuanced difference between this and your suggestion further down
the message is interesting, because the groupId will almost
necessarily contain the org name, but the implication of the name in
the groupId case is clearly of the package's provenance, rather than
the packager's identity.
2.) We should use the artifact id (jar name) as the package name in
my
opinion. The only issue with this is that it is sometimes extremely
generic. I have seen an artifact called `ri' (presumably `reference
implementation'). Apparently, they are relying on the fact that their
maven groupId is unique, but they don't seem to realize that the jar may
be free of that identifier. Most people would consider a case like this
to be an upstream bug.
Are you advocating for a subpackage for every jar here? I'm not sure
how I feel about that...
Again, look at apache-mime4j. The URL is
<
http://james.apache.org/mime4j/>. So is it james-mime4j?
apache-james-mime4j? mime4j? The possibilities are endless, which is why
I would choose apache-mime4j which is the upstream name for the jar that
everyone in the Java world already recognizes. Of course, we could solve
this forever and just use the full maven GAV as the name. The artifact
name would also be solved if deploying to a maven repo. But in any case,
I do not agree with coming up with Fedora's own unique names to add to
the existing mess.
I'm sure this will be dismissed as a joke by some (and maybe you were
joking?), but there are some very nice implications of doing this. It
certainly solves the name uniqueness issue and ends the debate about
what that unique name should be. With short package names like
"spring" and an ever-growing distribution, name collisions are
inevitable, but if you mandate that package names be things like
org.springframework-spring-core and whatnot, you eliminate that. The
names look strange compared to what people are used to, but I don't
think there's a strong argument that the "long" (G-A-V) names would
have any lasting negative impact. I cannot think of a case where
would _prevent_ someone from finding the package they seek. The
downside I see in this is that (I think) you're again talking about a
1:1 relationship between jars and packages, which may drastically
increase the number of subpackages we're maintaining. That may just
mean we've got extra incentive to make subpackage maintenance
"cheaper" (i.e., fewer extra lines in the spec, like what's happening
with javadocs right now). Added bonus: if we make that mass name
change a Fedora 18 feature, I am much less concerned about _any_
package naming debates in Fedora 17! :-)
(If this doesn't stir up discussion, I'm not sure what will).
--Andy
--
java-devel mailing list
java-devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/java-devel