On 02/16/2012 06:52 PM, Andy Grimm wrote:
I think the only reason (aside from "that's what JPackage
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
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
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.
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
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
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
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.