----- Original Message -----
From: "David Walluck" <david(a)zarb.org>
To: java-devel(a)lists.fedoraproject.org
Sent: Friday, February 17, 2012 4:19:45 AM
Subject: Re: [fedora-java] 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(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/java-devel