Fedora vs JPackage naming
 

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-'.

> 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.

> 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.

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...

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.

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.

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.
--
java-devel mailing list
java-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/java-devel

Fedora vs JPackage naming
 

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

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
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@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/java-devel

Fedora vs JPackage naming
 

tor 2012-02-16 klockan 14:58 -0500 skrev David Walluck:

> Part of the problem is the horrible paractice of renaming a jar to the
> package name.

The guidelines already requires the name provided by the build to exist,
either as a file or a symlink. The symlink case is:

* If the package provides a single JAR and the filename provided
by the build is neither %{name}-%{version}.jar nor %{name}.jar
then this file MUST be installed as %{name}.jar and a symbolic
link with the usual name must be provided.

https://fedoraproject.org/wiki/Packaging:Java#JAR_file_installation

/Alexander


--
java-devel mailing list
java-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/java-devel

Fedora vs JPackage naming
 

On 02/17/2012 12:03 AM, Alexander Boström wrote:
> tor 2012-02-16 klockan 14:58 -0500 skrev David Walluck:
>
>> Part of the problem is the horrible paractice of renaming a jar to the
>> package name.
>
> The guidelines already requires the name provided by the build to exist,
> either as a file or a symlink. The symlink case is:

Yes, but that is exactly what I am complaining about (what I called a
``horrible practice'. Well, actually I called it a ``paractice', but
that was only because I don't have a spell checker right now).

If the upstream project has decided not to provide an artifact with the
name `%{name}', then why must we invent one? This only adds to the
naming confusion that this thread has been trying to address.

In some cases, it's not even clear which artifact the packager is
supposed to rename because there may be multiple (equally important)
artifacts. Besides, my first thought would be that I named the package
incorrectly---it would not be that the upstream project must have named
their *own* artifacts incorrectly so that I must invent a new and better
name. Does anybody actually think this?

We may say that we know better than upstream projects in certain areas.
I will freely admit that. But, I don't think that ``making up names' is
one of them. And I also freely admit that sometimes the upstream project
changes its mind or makes names very generic, but this is not true of
the large majority of projects.
--
java-devel mailing list
java-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/java-devel

Fedora vs JPackage naming
 

fre 2012-02-17 klockan 01:03 -0500 skrev David Walluck:

> Yes, but that is exactly what I am complaining about (what I called a
> ``horrible practice'. Well, actually I called it a ``paractice', but
> that was only because I don't have a spell checker right now).
>
> If the upstream project has decided not to provide an artifact with the
> name `%{name}', then why must we invent one? This only adds to the
> naming confusion that this thread has been trying to address.

Having the package %{name} somewhere in there helps to prevent namespace
collisions, so it makes sense in a way. Except that it doesn't because
the build's name is still there!

The current guidelines means that in most cases there'll either be a
%{name}.jar file or symlink or there'll be a directory %{name} with all
the jars in it. Except in the case where the package contains exactly to
jars. Yes, that's weird.

> In some cases, it's not even clear which artifact the packager is
> supposed to rename because there may be multiple (equally important)
> artifacts.

Nope:

* If the package provides more than one JAR file, the
filenames assigned by the build MUST be used (without
versions).

/Alexander


--
java-devel mailing list
java-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/java-devel

Fedora vs JPackage naming
 

On 02/17/2012 01:33 AM, Alexander Boström wrote:
> Nope:
>
> * If the package provides more than one JAR file, the
> filenames assigned by the build MUST be used (without
> versions).

OK, but that is worse in a sense as it adds to the inconsitency even
more. Maybe in this case the policy assumes that artifacts will be
placed in a separate directory, %_javadir/%name? Although I have done
this myself in a good number of packages, I am now advocating a flat
structure in %_javadir using the upstream names (actually the name and
full version equivalent to maven <artifactId>-<version>) only.

Among the many problems with the non-flat approach is that it doesn't
work with the resolvers provided by ivy or gradle very well, and at the
same time, it lacks the maven dir structure so that can't be used with a
maven resolver either. Basically, the current policy fails all relevant
build use cases that I can come up with. I don't know how I can make my
case stronger than it already is. I do not recall a single case of name
collisions, but as you said, the policy does not prevent that anyway
unless a separate directory is used.

Another case is the current jboss work which is using %_javadir/jboss.
Obviously, that dir name is not equal to %_javadir/%name (and it
involves multiple separate packages all sharing and owning the dir
%_javadir/jboss). Again, I think this choice is arbitrary and getting
ridiculous and I can only reiterate what I've already stated on this topic.
--
java-devel mailing list
java-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/java-devel

Fedora vs JPackage naming
 

----- Original Message -----
> From: "David Walluck" <david@zarb.org>
> To: java-devel@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@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/java-devel
--
java-devel mailing list
java-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/java-devel

Fedora vs JPackage naming
 

----- Original Message -----
> From: "David Walluck" <david@zarb.org>
> To: java-devel@lists.fedoraproject.org
> Sent: Friday, February 17, 2012 8:46:22 AM
> Subject: Re: [fedora-java] Fedora vs JPackage naming
>
> On 02/17/2012 01:33 AM, Alexander Boström wrote:
> > Nope:
> >
> > * If the package provides more than one JAR file, the
> > filenames assigned by the build MUST be used
> > (without
> > versions).
>
> OK, but that is worse in a sense as it adds to the inconsitency even
> more. Maybe in this case the policy assumes that artifacts will be
> placed in a separate directory, %_javadir/%name? Although I have done
> this myself in a good number of packages, I am now advocating a flat
> structure in %_javadir using the upstream names (actually the name
> and
> full version equivalent to maven <artifactId>-<version>) only.
>
> Among the many problems with the non-flat approach is that it doesn't
> work with the resolvers provided by ivy or gradle very well, and at
> the
> same time, it lacks the maven dir structure so that can't be used
> with a
> maven resolver either. Basically, the current policy fails all
> relevant
> build use cases that I can come up with. I don't know how I can make
> my
> case stronger than it already is. I do not recall a single case of
> name
> collisions, but as you said, the policy does not prevent that anyway
> unless a separate directory is used.
>
> Another case is the current jboss work which is using
> %_javadir/jboss.
> Obviously, that dir name is not equal to %_javadir/%name (and it
> involves multiple separate packages all sharing and owning the dir
> %_javadir/jboss). Again, I think this choice is arbitrary and getting
> ridiculous and I can only reiterate what I've already stated on this
> topic.

Yes the choice is arbitrary and I'm not fan of this. But there is no size fits them all.
This choices are made by the packagers if they feel that given artifacts are coming from the same project and it would
help them even remotely to achieve their tasks(e.g. by allowing them to add single folder to classpath instead of enumerating dozens of jars manually) I can understand the reasoning. Plus in the guidelines there is a statement that if package installs more than 2 jars they should go into _javadir/name/ which at least for me makes it perfectly viable place for installation if your package is coming from the same source and you depend on that previous package. I'm sure that this eliminates a number of the arbitrary-looking choices but I guess this is not clearly stated in the guidelines thus I'll really appreciate someone with better English than mine to provide the rewording needed and get the guidelines updated. We should always strive for cleaner guidelines.

Alex

> --
> java-devel mailing list
> java-devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/java-devel
--
java-devel mailing list
java-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/java-devel

Fedora vs JPackage naming
 

On 02/17/2012 02:29 AM, Aleksandar Kurtakov wrote:
> 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.

Does it set the version properly too? I know that certain characters are
not allowed in the RPM version string so it would have to normalize it
somehow. Currently, we don't have this on RHEL 6, so I haven't actually
seen it in action.

The Fedora Release tag policy prevents proper versioning of
BuildRequires since important parts of the version string end up in the
Release tag for no good reason. Since RPM compares both the V and the R,
moving things from V to R doesn't really make sense. RPM also compares
text strings in both, and while it may not exactly match how maven or
osgi compares, I think it's better than nothing and at least internally
consistent.

> 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.

I guess I would say to just pick one. If we have a policy that each
package must have a POM (or OSGI support---your choice), then each
package is also guarnateed to have a unique name in those systems.

> 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).

OK, you have some point to this in that we can start using these names
and pretend that the package name doesn't exist. But this only works if
the artifact names and locations are fixed too, right?

> 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 never said anything bad about your tool. If you look at what I said,
my choice was 100% driven by bandwidth concerns and my crappy internet
speed. It had nothing to do with software even. As I think you know, I
used to use Eclipse a lot in the past (especially when I was doing Java
development), and if I was able to do development on my local machine
I'd probably be using it now.

So again, I have nothing bad to say about your tool. But, I wonder if
parts of it are not tied to the GUI, then we could prehaps reuse a lot
of code to provide a headless solution? I am not saying that you (or I)
would be willing to code such a thing, but I am wondering if it makes sense.

> 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.

So, should we wait for Jigsaw? Will Jigsaw actually solve anything? If
yes, then we could at least start to plan for it.

> 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.

Good point. But if there were such specific standards, a tool can
generate to such standards, and rpmlint already exists to complain about
such things, although I don't know that it's actually deployed for Fedora.
--
java-devel mailing list
java-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/java-devel