On Thu, Feb 16, 2012 at 2:58 PM, David Walluck <david@xxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxxxx > https://admin.fedoraproject.org/mailman/listinfo/java-devel -- java-devel mailing list java-devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/java-devel
