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
