----- Original Message ----- > From: "David Walluck" <david@xxxxxxxx> > To: java-devel@xxxxxxxxxxxxxxxxxxxxxxx > Sent: Friday, February 17, 2012 4:19:45 AM > Subject: Re: Fedora vs JPackage naming > > 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 I've spend enough time on getting this working and it really is now. If your package installs pom.xml file it will have Provide: mvn(gid:aid) If your package is an osgi bundle it will have Provide: osgi(bundle-symbolic-name) If it installs pom.xml and is osgi bundle it will have both Provides. When in doubt just use that or use yum to tell you the package name. > 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. I don't understand this point. We can not use maven gid:aid or osgi symbolic-name as package names. The mess will become way bigger in this case - it will be: * for maven packages use gid-aid as package names * for osgi packages use symbolic names * for jars that are neither - stick to the project names * for packages that are both maven and osgi ? - should we give the packager a choice? I don't feel it's right to ask osgi developers to care about maven and vise-versa so letting the packager makes a choice seems like the right choice. But just imagine the mess this will be !!! I'm definetely not looking for this. People should learn to use the virtual provides for the time being (until there is suitable! module system in java world). > > > 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 cannot work with tools not providing me autocomplete for package names. No templates for commonly used tasks. No hover info saving me time from running different console tools and grepping their output. Tools asking me to switch between windows just to check whether the build finished. Having to use one more tool for merging and etc. etc. Should I continue? I guess everyone sees the point - I don't mind and don't bash others for their tools of choice so why don't people accept that others have their freedom of choice and if something is not suitable for them because whatever one thinks is best might be even less suitable for others. I know that this is off-topic here but I'm really tired of seeing this remarks. It is my choice to make this tool this way and people should respect that. Everyone is free to come with better(where better means more suitable for him) ones > > 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). There is one huge difference here - perl and python are modulized upstream, with every module having it's own tarball an release (most of the times). Thus this comparison is irrelevant here until this happens upstream in java land. > > 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. If we want to be more of a product than a bunch of random packages I think that this things should be set distro wide so there are no distro wide and enforced in a way that we don't see the current mess. Believe it or not but simple things like formatting and _mv,_install.. vs mv, install add to the mess at least equally as the package names if one has to touch every java package to keep the stack working. Alex > -- > 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
