Re: Fedora vs JPackage naming

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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-'.

> 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.

> 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.

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...

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.

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.

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.
--
java-devel mailing list
java-devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/java-devel



[Index of Archives]     [Red Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]

  Powered by Linux