After running into a few complicated naming situations, I decided it would be worthwhile to pose this question to the list. For context, the current Fedora package naming guidelines say this:
"When naming a package, the name should match the upstream tarball or project name from which this software came. In some cases, this naming choice may be more complicated. If this package has been packaged by other distributions/packagers in the past, then you should try to match their name for consistency. In any case, try to use your best judgement, and other developers will help in the final decision."
In the java world, a few issues come into play.
1) the history of jpackage naming, where a packages are often named according to the section of the apache project from which they came.
2) the upstream tarball naming and jar file names, which typically lack the "ws-commons" prefix.
3) the existing Fedora packages, where we have apache-commons-* , xml-commons-*, one ws-commons-* package, and one ws-* package.
4) apache's own naming in github is different from their svn naming (partly due to a lack of hierarchy):
https://github.com/apache/webservices-axiom
versus
http://svn.apache.org/viewvc/webservices/commons/tags/axiom/
5) If we go with short names (to match the jar files), we have a greater risk of collision with other project names, e.g., http://savannah.nongnu.org/projects/axiom
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.
(And if this topic has already been beaten to death, I apologize. I couldn't find a documented resolution, though.)
Thanks.
--Andy
On 02/16/2012 02:21 PM, Andy Grimm wrote:
- 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-'.
- 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.
- 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.
- 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.
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:
- 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
- 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.
- 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.
- 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
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.
----- 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
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.
----- Original Message -----
From: "David Walluck" david@zarb.org To: java-devel@lists.fedoraproject.org Sent: Friday, February 17, 2012 9:59:18 AM Subject: Re: [fedora-java] 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.
Yes, there is Provides: osgi(org.apache.commons.codec) = 1.6.0 for apache-commons-codec. I'm not aware of the characters problem for the osgi case and versions in the maven case doesn't make sense as we ignore them. Though having the version in the provides wouldn't hurt - if someone wants to enhance the maven provides generator - the code is at http://git.fedorahosted.org/git/?p=javapackages.git . Assuming that others are more interested in the maven case I'll be happy to guide them in achieving this. I get it to the point where it serves the generic Fedora case well and let the community enhance it if someone needs the version. RHEL is out of question in this thread and I would not comment it at all here.
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.
Well, I'm not sure how the release tag will be a problem if e.g. using Requires: osgi(org.apache.commons.codec) >= 1.6.0 . Note that the bundle version is used not the package version so the release is irrelevant unless we try to fight other issues with this like class versions, apiincompatibilities and etc. which are different problems in my eyes.
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.
Yes, but we already have too few contributors and trying to force them either the osgi or maven route will probably make them stop contributing. That's why I think we can not make this choice until there is a defacto module system.
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?
Well, we are working hard on this too and such cases are very rare nowadays but if there is something this is a bug and deserves a bug report.
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.
Sorry David, I'm bit touchy on the subject because I see these remarks too often and most of the time from people that haven't even tried something. My reply is because of my personal feelings about the topic and how will a number of people read it (though I know exactly what you ment) that's why I commented it. There are still options to use eclipse locally with projects on remote filesystem but this thread is not the right place. Technically it is adding one class implementing IApplication that will call the command with the correct parameters that will allow people to run it headless(without gui) aka eclipse -application myapp . If there is anything else needed in the code I'll be happy to do it but I would not drive such an effort myself. I care for people being able to use my work but people should be ready to step in :).
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.
Wait - no . Jigsaw is work in progress AFAIK so people should join there and help drive it for our needs.
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.
Rpmlint is supposed to be used during review but I would not say it's deployed distro wide. At least not in the way it was at Mandriva - with build system rejecting builds on certain rpmlint errors. But this is fight I'm not ready to step in.
Alex
-- java-devel mailing list java-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/java-devel
On 02/17/2012 03:35 AM, Aleksandar Kurtakov wrote:
Yes, there is Provides: osgi(org.apache.commons.codec) = 1.6.0 for apache-commons-codec. I'm not aware of the characters problem for the osgi case and versions in the maven case doesn't make sense as we ignore them. Though having the version in the provides wouldn't hurt
I would like to, for example, BuildRequires >= <version in pom>. I give a specific example later on.
someone needs the version. RHEL is out of question in this thread and I would not comment it at all here.
All I mean is that the changes apparently require changes to RPM itself so that unlike jpackage-utils macros, the changes are not portable. Unless I am mistaken. For example, we can install jpackage-utils on RHEL (or anywhere else) and immediately get the support for various macros, etc.
Well, I'm not sure how the release tag will be a problem if e.g. using Requires: osgi(org.apache.commons.codec) >= 1.6.0 . Note that the bundle version is used not the package version so the release is irrelevant unless we try to fight other issues with this like class versions, apiincompatibilities and etc. which are different problems in my eyes.
A typical jboss version 1.0.0.CR2. I would like to say >= 1.0.0.CR2. But, I can't, because it's 1.0.0-99.CR2 or something instead. Even though putting the CR2 in the version string would be absolutely fine except that it violates some stupid policy that is apparently not based on actual RPM versioning semantics and again some abitrary prefs of some people.
Yes, but we already have too few contributors and trying to force them either the osgi or maven route will probably make them stop contributing. That's why I think we can not make this choice until there is a defacto module system.
There is no policy that already dictates, e.g., support for maven?
Well, we are working hard on this too and such cases are very rare nowadays but if there is something this is a bug and deserves a bug report.
Well, package xerces-j2 historically installed xerces-j2.jar, but it should have been xercesImpl.jar all along because this is what everything and everybody expects.
exactly what you ment) that's why I commented it. There are still options to use eclipse locally with projects on remote filesystem but this thread is not the right place. Technically it is adding one
Yes, I know some things such as sshfs, but anyway.
----- Original Message -----
From: "David Walluck" david@zarb.org To: java-devel@lists.fedoraproject.org Sent: Friday, February 17, 2012 11:06:21 AM Subject: Re: [fedora-java] Fedora vs JPackage naming
On 02/17/2012 03:35 AM, Aleksandar Kurtakov wrote:
Yes, there is Provides: osgi(org.apache.commons.codec) = 1.6.0 for apache-commons-codec. I'm not aware of the characters problem for the osgi case and versions in the maven case doesn't make sense as we ignore them. Though having the version in the provides wouldn't hurt
I would like to, for example, BuildRequires >= <version in pom>. I give a specific example later on.
This should work just fine once someone implements adding version information to the maven provides generator assuming you stick to using the mvn(gid:aid) format.
someone needs the version. RHEL is out of question in this thread and I would not comment it at all here.
All I mean is that the changes apparently require changes to RPM itself so that unlike jpackage-utils macros, the changes are not portable. Unless I am mistaken. For example, we can install jpackage-utils on RHEL (or anywhere else) and immediately get the support for various macros, etc.
Nope, no changes to RPM itself are required. RPM provides an extension point for dependency generators which we have implemented in entirely separate project and shipped with jpackage-utils in Fedora for quite some time. See http://www.rpm.org/wiki/PackagerDocs/DependencyGenerator for details.
Well, I'm not sure how the release tag will be a problem if e.g. using Requires: osgi(org.apache.commons.codec) >= 1.6.0 . Note that the bundle version is used not the package version so the release is irrelevant unless we try to fight other issues with this like class versions, apiincompatibilities and etc. which are different problems in my eyes.
A typical jboss version 1.0.0.CR2. I would like to say >= 1.0.0.CR2. But, I can't, because it's 1.0.0-99.CR2 or something instead. Even though putting the CR2 in the version string would be absolutely fine except that it violates some stupid policy that is apparently not based on actual RPM versioning semantics and again some abitrary prefs of some people.
Again, having proper mvn(gid:aid) = pom_version provides should serve this purpose. There should be just someone motivated to enhance the current generator.
Yes, but we already have too few contributors and trying to force them either the osgi or maven route will probably make them stop contributing. That's why I think we can not make this choice until there is a defacto module system.
There is no policy that already dictates, e.g., support for maven?
If it's build with maven, maven integration is a MUST. Otherwise maven integration is a SHOULD which I read as non-mandatory (aka you can choose to not deal with it) but nice-to-have (aka you can't object if someone else does it).
Well, we are working hard on this too and such cases are very rare nowadays but if there is something this is a bug and deserves a bug report.
Well, package xerces-j2 historically installed xerces-j2.jar, but it should have been xercesImpl.jar all along because this is what everything and everybody expects.
Well, xml libs are so many and so different that we all would live in a better world once projects learn to use the xml apis in the JDK. So the right fix for this one in my eyes is fix your project to not depend on xerces instead of care how is it packaged.
Alex
exactly what you ment) that's why I commented it. There are still options to use eclipse locally with projects on remote filesystem but this thread is not the right place. Technically it is adding one
Yes, I know some things such as sshfs, but anyway.
java-devel mailing list java-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/java-devel
On 02/17/2012 10:42 AM, Aleksandar Kurtakov wrote:
Well, package xerces-j2 historically installed xerces-j2.jar, but it should have been xercesImpl.jar all along because this is what everything and everybody expects.
Well, xml libs are so many and so different that we all would live in a better world once projects learn to use the xml apis in the JDK. So the right fix for this one in my eyes is fix your project to not depend on xerces instead of care how is it packaged.
Alex
What "everybody expects" is a very large quantifier. I can just be a prick and say: hey, I did not expect that. ;-)
Depending on xerces might be a valid choice. I don't want to know the actual requirements or arguments. But we should just be providing choice.
In this case: use the existing xerces rpm or do it yourself in the way you like. :-)
Carlo
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
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.
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
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.
----- 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
On 02/17/2012 02:41 AM, Aleksandar Kurtakov wrote:
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
As to the non-flat dir structure and renaming of jars:
Does it work with ant out of the box? No. Does it work with ivy out of the box? No. Does it work with gradle out of the box? No. Does it work with maven out of the box (without the depmap hack)? No.
So, my preference stems from these requirements and not what the guidelines currently say or what the packager prefers. I'd prefer a new guideline that meets all four requirements above.
----- Original Message -----
From: "David Walluck" david@zarb.org To: java-devel@lists.fedoraproject.org Sent: Friday, February 17, 2012 10:05:01 AM Subject: Re: [fedora-java] Fedora vs JPackage naming
On 02/17/2012 02:41 AM, Aleksandar Kurtakov wrote:
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
As to the non-flat dir structure and renaming of jars:
Does it work with ant out of the box? No.
-1 Nothing works with ant out of the box.
Does it work with ivy out of the box? No.
+1 but there are only a few packages in Fedora that use ivy.
Does it work with gradle out of the box? No.
-1 Well, gradle is not in Fedora and there is no one working on it. It's design is so badly broken that it will not work for pure source builds without network access without a major rewrite so I don't care about it until this happens.
Does it work with maven out of the box (without the depmap hack)? No.
-1 For something to work with maven out of the box there has to be a maven repo. But files installed only in maven repo will fail usage from all other build systems. This can be achieved but it's maven specific development thus irrelevant to the general considerations.
Does it work with pde.build out of the box? No. -1 Nothing works with pde.build out of the box.
Does it work with tycho out of the box? No. -1 This is actually in the same both as maven - it needs it's p2 repo but this is smth the people that care for maven should do - fix/extend their own stuff.
So the only solution that at least have chances to satisfy our needs is Ivy :).
Alex
So, my preference stems from these requirements and not what the guidelines currently say or what the packager prefers. I'd prefer a new guideline that meets all four requirements above. -- java-devel mailing list java-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/java-devel
On 02/17/2012 03:43 AM, Aleksandar Kurtakov wrote:
So the only solution that at least have chances to satisfy our needs is Ivy :).
The point is that something as simple as %_javadir/<artifactId>-<version>.<extension> probably satisfies 3 out of 4 requirements, and ivy also supports maven artifact patterns (really, it is just another location, which could be a simple symlink).
So I would agree with you if supporting these crazy builds systems requires a lot (or even a little) extra work.
But it seems to me that we get support for free (or at least as best we can, by sticking to the simple flat dir and naming structure above).
On 02/17/2012 10:10 AM, David Walluck wrote:
On 02/17/2012 03:43 AM, Aleksandar Kurtakov wrote:
So the only solution that at least have chances to satisfy our needs is Ivy :).
The point is that something as simple as %_javadir/<artifactId>-<version>.<extension> probably satisfies 3 out of 4 requirements, and ivy also supports maven artifact patterns (really, it is just another location, which could be a simple symlink).
So I would agree with you if supporting these crazy builds systems requires a lot (or even a little) extra work.
But it seems to me that we get support for free (or at least as best we can, by sticking to the simple flat dir and naming structure above). -- java-devel mailing list java-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/java-devel
I just would like to see maven artifacts 'properly' installed in /usr/share/maven/repository. Then we can let upstream maven (and other tools) use that.
Carlo
----- Original Message -----
From: "Carlo de Wolf" cdewolf@redhat.com To: java-devel@lists.fedoraproject.org Sent: Friday, February 17, 2012 11:49:09 AM Subject: Re: [fedora-java] Fedora vs JPackage naming
On 02/17/2012 10:10 AM, David Walluck wrote:
On 02/17/2012 03:43 AM, Aleksandar Kurtakov wrote:
So the only solution that at least have chances to satisfy our needs is Ivy :).
The point is that something as simple as %_javadir/<artifactId>-<version>.<extension> probably satisfies 3 out of 4 requirements, and ivy also supports maven artifact patterns (really, it is just another location, which could be a simple symlink).
So I would agree with you if supporting these crazy builds systems requires a lot (or even a little) extra work.
But it seems to me that we get support for free (or at least as best we can, by sticking to the simple flat dir and naming structure above). -- java-devel mailing list java-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/java-devel
I just would like to see maven artifacts 'properly' installed in /usr/share/maven/repository. Then we can let upstream maven (and other tools) use that.
I would even say that this is the only viable solution for the maven and friends and this doesn't interfere with the other buildsystems so everyone that cares about Maven - Join Carlo and help him achieve that
Alex
Carlo
java-devel mailing list java-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/java-devel
On 02/17/2012 04:53 AM, Aleksandar Kurtakov wrote:
I would even say that this is the only viable solution for the maven and friends and this doesn't interfere with the other buildsystems so everyone that cares about Maven - Join Carlo and help him achieve that
I discussed this on IRC with sochotni recently. I thought the idea was to do a normal maven deploy with altDeploymentRepository set to %{buildroot}%{_datadir}/maven/repository.
But there are two caveats:
1.) We can't leave the real files at this location because other tools need access, too. So I would say move it to %__javadir and symlink it back to the repo location. Others may have a better idea.
2.) Fedora wants to support (only) unversioned files. The question is how to handle the version since in a normal deploy the version will be harcoded in both the directory and file names. It's possible somehow to handle this with the proper settings.xml so we could remove all (or most) of our patches to maven.
On 02/17/2012 11:10 AM, David Walluck wrote:
On 02/17/2012 04:53 AM, Aleksandar Kurtakov wrote:
I would even say that this is the only viable solution for the maven and friends and this doesn't interfere with the other buildsystems so everyone that cares about Maven - Join Carlo and help him achieve that
I discussed this on IRC with sochotni recently. I thought the idea was to do a normal maven deploy with altDeploymentRepository set to %{buildroot}%{_datadir}/maven/repository.
But there are two caveats:
1.) We can't leave the real files at this location because other tools need access, too. So I would say move it to %__javadir and symlink it back to the repo location. Others may have a better idea.
Vice versa symlink. ;-) (Truthfully I don't care that much.)
2.) Fedora wants to support (only) unversioned files. The question is how to handle the version since in a normal deploy the version will be harcoded in both the directory and file names. It's possible somehow to handle this with the proper settings.xml so we could remove all (or most) of our patches to maven.
Upstream maven can't handle 'unversioned' files.
However, we can plug an extension into upstream maven which handles our policy. This would make it also usable on other platforms.
https://github.com/wolfc/fedora-maven
Carlo
Time to give my POV here :).
----- Original Message -----
From: "Andy Grimm" agrimm@gmail.com To: "java-devel" java-devel@lists.fedoraproject.org Sent: Thursday, February 16, 2012 9:21:02 PM Subject: [fedora-java] Fedora vs JPackage naming
After running into a few complicated naming situations, I decided it would be worthwhile to pose this question to the list. For context, the current Fedora package naming guidelines say this:
"When naming a package, the name should match the upstream tarball or project name from which this software came. In some cases, this naming choice may be more complicated. If this package has been packaged by other distributions/packagers in the past, then you should try to match their name for consistency. In any case, try to use your best judgement, and other developers will help in the final decision."
In the java world, a few issues come into play.
- the history of jpackage naming, where a packages are often named
according to the section of the apache project from which they came.
I would say keeping jpackage compatibility but if upstreams have moved/changed, the jpackage name is ambiguous nowadays or even there is a name that matches other things in fedora better we can live without this compatibility.
- the upstream tarball naming and jar file names, which typically
lack the "ws-commons" prefix.
There are too many Java projects that have all 3 (project, tarball, jar) names differ or even worse jars from the same tarball/projects use different name schemes. This is a case where I think we don't have better solution but to trust the packager and the reviewer working on the package to come with the best package name. I doubt anyone can come up with a policy that is less than stupid if the upstream project can not cope with that.
- the existing Fedora packages, where we have apache-commons-* ,
xml-commons-*, one ws-commons-* package, and one ws-* package.
I would say that these package names are because of legacy reasons. WS/XML projects have sub-projects floating around in them and commons is just to common to mean something. We can even use just codec/lang if we go on removing the unneeded parts. That's why we have always had them fully prefixed - jakarta-commons, apache-commons and etc. I don't see a good reason to change that.
- apache's own naming in github is different from their svn naming
(partly due to a lack of hierarchy):
https://github.com/apache/webservices-axiom
versus
http://svn.apache.org/viewvc/webservices/commons/tags/axiom/
As apache doesn't have official git repo probably we should not care about that until they come up with one.
- If we go with short names (to match the jar files), we have a
greater risk of collision with other project names, e.g., http://savannah.nongnu.org/projects/axiom
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 opinion is that we should try to match the artifactId in the maven case and if it looks ambiguous add the project name as we currently do. I really trust packagers to make the right choice. Once there is an all Java land module system this things will settle down. I really encourage people interested in this area to join the Jigsaw/Penrose projects and help people there to come up with a module system that will work for us. We don't have to think of package names and etc. because until there is a heavily used module system in the JVM we would never manage to have proper and sensible naming. Until then I don't see better choice than going on case by case.
P.S. Every mass package rename with Jigsaw scheduled for Java 8 would do nothing more but enhance the mess.
Alex
(And if this topic has already been beaten to death, I apologize. I couldn't find a documented resolution, though.)
Thanks.
--Andy
java-devel mailing list java-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/java-devel
java-devel@lists.fedoraproject.org
-
Aleksandar Kurtakov -
Alexander Boström -
Andy Grimm -
Carlo de Wolf -
David Walluck