On 02/16/2012 06:52 PM, Andy Grimm wrote: > 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. Well, some projects literally did use the `ws-' prefix upsteam, e.g., ws-addressing, which jpackage called ws-fx-addressing (because wx-fx is the top-level project/SCM module). So while these names didn't come from nowhere, the examples you cited about `ws-commons' I agree with you on, as I don't see that prefix anywhere in the artifact names upstream. I don't agree with the Debian naming. In Java, you cannot say definitively that this is definitely a library and this is definitely an application. Thus, I am pretty sure that it is again an arbitrary choice that no one uses that in the Java world. > 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. I have seen a case where RPMS named with `google-' are actually upstream RPMS provided by Google itself as opposed to a Linux distro which typically just uses the name of the project and not the vendor. Again, from our perspective, the vendor is fedora, not google. And no one is advocating adding `fedora-' to all package names (or at least I am not, but I think it does prove my point). But again, sometimes the name appears also in the artifact itself, in which case, we can't help but use it. > Are you advocating for a subpackage for every jar here? I'm not sure > how I feel about that... Here, I did not argue that explictly, and while I am sure it's a pain to have to package things that way, it is actually the best way. The two main arguments for it are: 1.) maven and/or OSGi already provides the granularity, so we just have to implment it, not design it 2.) if we keep one large monolithic package, we're stuck with instances where we arbitrarily want to drop certain depdencies just because they aren't required by the core (therefore, a projct with multipel dependencies usually ends up with too many dependencies or two few, since they aren't split on a per-module basis). > org.springframework-spring-core and whatnot, you eliminate that. The > names look strange compared to what people are used to, but I don't And I think that the only argument that I've heard is that org.springframework-spring-core is not as pretty (visually) as spring-core... or is it spring2-core. But we're not designing a user-interface, so this shouldn't really come into play. akurtkov told me that Fedora will have either maven() or osgi() style provides. This allows that sort of name to be used in Provides/Requires, but so long as it's not used in the package names, it won't solve all problems. > 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! :-) I made myself a shell script that can spit out a .spec based on the maven poms. Unfortunately, it does not split out a subpackage for every module. I believe akurtakov has something for Eclipse, but my problem is that I don't want to (and cannot) fire up a large IDE to work on RPMS. I cannot do to logistical factors such as working remotely over a very slow uplink. I would not worry about the number of packages increasing (as perl and python are already fully modulized I think, yet no one complains about that). If you're complaining about work for the packager, then a tool to automate the process can help. However, even little thinks like not setting the tab stop where I like it is enough for me to get annoyed at such a tool. -- java-devel mailing list java-devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/java-devel
