It seems that a significant number of JAR files under /usr/share/java do not declare their dependencies using the Class-Path manifest attribute.
As a result, the dependencies need to be collected manually and included with the final link (typically, in the -classpath argument to /usr/bin/java). This is mightily inconvenient and leaks implementation details across Java RPM package boundaries. (I don't think %jpackage_script does recursive linking, unlike the JVM.)
rpmlint flags usage of the Class-Path attribute:
http://fedoraproject.org/wiki/Packaging:Java#class-path-in-manifest
But why?
Quoting Florian Weimer (2013-05-27 15:01:38)
It seems that a significant number of JAR files under /usr/share/java do not declare their dependencies using the Class-Path manifest attribute.
As a result, the dependencies need to be collected manually and included with the final link (typically, in the -classpath argument to /usr/bin/java). This is mightily inconvenient and leaks implementation details across Java RPM package boundaries. (I don't think %jpackage_script does recursive linking, unlike the JVM.)
rpmlint flags usage of the Class-Path attribute:
http://fedoraproject.org/wiki/Packaging:Java#class-path-in-manifest
But why?
Since nobody replied, I will try...
Because in 99.9% percent of cases this Class-Path attribute would be incorrect. It has to be generated/added during build, but at that time it's unknown where those dependent jar files end up on the filesystem.
It also enables us to use alternative implementations and switch them without changing all dependent applications (though this is less important/needed).
The rule has been around for a long time so I guess there might be other reasons as well.
In my head the reasoning sounds like this: A: Can we make Class-Path work in most (let's say 90%) of cases? B: No, we'd have to modify manifests on the fly with some ugly scripts A: Ok, so let's just simplify and get rid of it
That said, I would be possible to create jar files with correct Manifests with XMvn. That way maintainer wouldn't have to do much (if anything). There are probably good reasons not to do this though.
On 05/27/2013 06:08 PM, Stanislav Ochotnicky wrote:
Quoting Florian Weimer (2013-05-27 15:01:38)
It seems that a significant number of JAR files under /usr/share/java do not declare their dependencies using the Class-Path manifest attribute.
As a result, the dependencies need to be collected manually and included with the final link (typically, in the -classpath argument to /usr/bin/java). This is mightily inconvenient and leaks implementation details across Java RPM package boundaries. (I don't think %jpackage_script does recursive linking, unlike the JVM.)
rpmlint flags usage of the Class-Path attribute:
http://fedoraproject.org/wiki/Packaging:Java#class-path-in-manifest
But why?
Since nobody replied, I will try...
Because in 99.9% percent of cases this Class-Path attribute would be incorrect. It has to be generated/added during build, but at that time it's unknown where those dependent jar files end up on the filesystem.
But that's because the policy encourages to make the paths non-predictable:
"If a project offers the choice of packaging it as a single monolithic jar or several ones, the split packaging should be preferred."
"Alternatively, the file can be installed to the subdirectory %{_javadir}/%{name}/ under its usual name."
"Packages CAN place JAR files into subdirectories."
"If the package provides more than one JAR file, the filenames assigned by the build MUST be used (without versions)."
You need stable JAR names at well-defined locations for valid Class-Path references. The benefits of unpredictable naming of JAR files are less clear to me.
The rule has been around for a long time so I guess there might be other reasons as well.
The existence of the Class-Path attribute is not widely known, and I was surprised to see it mentioned in the policy.
My experience using it for dependency management has been extremely positive. It certainly was less error-prone than guessing dependencies manually. (I remember one case where a JAR file was inadvertently put on the classpath which replaced some system XML parser with an HTML parser. Yuck.)
On 05/29/13 10:13, Florian Weimer wrote:
The existence of the Class-Path attribute is not widely known, and I was surprised to see it mentioned in the policy.
Yes it is, it's very well-known, and is almost universally rejected. It bakes hard paths into jarfiles and overrides -classpath. In other words, it has similar disadvantages to -RPATH.
It's not really suitable for any use, IMO.
Andrew.
On 29/05/13 10:30, Andrew Haley wrote:
On 05/29/13 10:13, Florian Weimer wrote:
The existence of the Class-Path attribute is not widely known, and I was surprised to see it mentioned in the policy.
Yes it is, it's very well-known, and is almost universally rejected. It bakes hard paths into jarfiles and overrides -classpath. In other words, it has similar disadvantages to -RPATH.
It's not really suitable for any use, IMO.
I was about post exactly the same response but Andrew beat me to it. I'll just underline
_very well-known_
_almost universally rejected_
and
_not really suitable for any use_
Hope that helps ;-)
regards,
Andrew Dinn -----------
On Wed, 29 May 2013, Andrew Dinn wrote:
On 29/05/13 10:30, Andrew Haley wrote:
On 05/29/13 10:13, Florian Weimer wrote:
The existence of the Class-Path attribute is not widely known, and I was surprised to see it mentioned in the policy.
Yes it is, it's very well-known, and is almost universally rejected. It bakes hard paths into jarfiles and overrides -classpath. In other words, it has similar disadvantages to -RPATH.
It's not really suitable for any use, IMO.
I was about post exactly the same response but Andrew beat me to it. I'll just underline
_very well-known_
_almost universally rejected_
and
_not really suitable for any use_
Hope that helps ;-)
I'd like to point out a few additional bits of information:
- Class-Path also works with relative paths - Class-Path does not work in combination with -classpath, at all; it only works with -jar (and in containers which support it, of course) - There is also an "installed extension" mechanism which is arguably not so great but is standard: http://docs.oracle.com/javase/7/docs/technotes/guides/extensions/spec.html http://docs.oracle.com/javase/7/docs/technotes/guides/jar/jar.html#Main_Attr...
Finally, I think it's worth mentioning that JBoss Modules is a class loading environment that allows complete specification of interdependencies which any Java application can take advantage of. I would love to see Fedora use it. Just sayin'. ;)
On 05/29/2013 03:30 PM, David M. Lloyd wrote:
On Wed, 29 May 2013, Andrew Dinn wrote:
On 29/05/13 10:30, Andrew Haley wrote:
On 05/29/13 10:13, Florian Weimer wrote:
The existence of the Class-Path attribute is not widely known, and I was surprised to see it mentioned in the policy.
Yes it is, it's very well-known, and is almost universally rejected. It bakes hard paths into jarfiles and overrides -classpath. In other words, it has similar disadvantages to -RPATH.
It's not really suitable for any use, IMO.
I was about post exactly the same response but Andrew beat me to it. I'll just underline
_very well-known_
_almost universally rejected_
and
_not really suitable for any use_
Hope that helps ;-)
I'd like to point out a few additional bits of information:
- Class-Path also works with relative paths
- Class-Path does not work in combination with -classpath, at all; it only works with -jar (and in containers which support it, of course)
- There is also an "installed extension" mechanism which is arguably not so great but is standard:
http://docs.oracle.com/javase/7/docs/technotes/guides/extensions/spec.html http://docs.oracle.com/javase/7/docs/technotes/guides/jar/jar.html#Main_Attr...
Finally, I think it's worth mentioning that JBoss Modules is a class loading environment that allows complete specification of interdependencies which any Java application can take advantage of. I would love to see Fedora use it. Just sayin'. ;)
I would like to see jboss modules instead of new JMODs in JDK8 (project jigsaw....)
J.
Everyone should just use OSGI ;-)
On 18 June 2013 15:44, Jiri Vanek jvanek@redhat.com wrote:
On 05/29/2013 03:30 PM, David M. Lloyd wrote:
On Wed, 29 May 2013, Andrew Dinn wrote:
On 29/05/13 10:30, Andrew Haley wrote:
On 05/29/13 10:13, Florian Weimer wrote:
The existence of the Class-Path attribute is not widely known, and I was surprised to see it mentioned in the policy.
Yes it is, it's very well-known, and is almost universally rejected. It bakes hard paths into jarfiles and overrides -classpath. In other words, it has similar disadvantages to -RPATH.
It's not really suitable for any use, IMO.
I was about post exactly the same response but Andrew beat me to it. I'll just underline
_very well-known_
_almost universally rejected_
and
_not really suitable for any use_
Hope that helps ;-)
I'd like to point out a few additional bits of information:
- Class-Path also works with relative paths
- Class-Path does not work in combination with -classpath, at all; it
only works with -jar (and in containers which support it, of course)
- There is also an "installed extension" mechanism which is arguably not
so great but is standard: http://docs.oracle.com/javase/**7/docs/technotes/guides/** extensions/spec.htmlhttp://docs.oracle.com/javase/7/docs/technotes/guides/extensions/spec.html http://docs.oracle.com/javase/**7/docs/technotes/guides/jar/** jar.html#Main_Attributeshttp://docs.oracle.com/javase/7/docs/technotes/guides/jar/jar.html#Main_Attributes
Finally, I think it's worth mentioning that JBoss Modules is a class loading environment that allows complete specification of interdependencies which any Java application can take advantage of. I would love to see Fedora use it. Just sayin'. ;)
I would like to see jboss modules instead of new JMODs in JDK8 (project jigsaw....)
J.
-- java-devel mailing list java-devel@lists.**fedoraproject.org java-devel@lists.fedoraproject.org https://admin.fedoraproject.**org/mailman/listinfo/java-**develhttps://admin.fedoraproject.org/mailman/listinfo/java-devel
On 06/20/2013 11:31 AM, Mat Booth wrote:
Everyone should just use OSGI ;-)
Ugh, quoted the entire message to add one line...
In any case, OSGi has Bundle-ClassPath (as well as directives such as Embed-Dependency in maven-bundle-blugin).
And this is better how? Or is it just a new way to perform the same bad tricks?
On Thu, 20 Jun 2013, David Walluck wrote:
On 06/20/2013 11:31 AM, Mat Booth wrote:
Everyone should just use OSGI ;-)
Ugh, quoted the entire message to add one line...
In any case, OSGi has Bundle-ClassPath (as well as directives such as Embed-Dependency in maven-bundle-blugin).
And this is better how? Or is it just a new way to perform the same bad tricks?
OSGi covers some similar linking problems. And, because it exists, it has many proponents. But it is far from being the best solution for the problems typically faced by operating system distributions containing Java components. I would say it's not the best solution for many other problems either, but I don't really want to engage in that particular argument at this time. :)
Solutions like JBoss Modules and Jigsaw are specifically designed to solve this class of problems. Though the soonest we'll see any module solution in Java is going to be JDK 9, not JDK 8.
On 05/29/2013 11:30 AM, Andrew Haley wrote:
On 05/29/13 10:13, Florian Weimer wrote:
The existence of the Class-Path attribute is not widely known, and I was surprised to see it mentioned in the policy.
Yes it is, it's very well-known, and is almost universally rejected. It bakes hard paths into jarfiles and overrides -classpath. In other words, it has similar disadvantages to -RPATH.
I finally experimented with this:
https://github.com/fweimer/classpath-manifest-override
The gist appears to be that overriding Class-Path entries is possible if the main class is not executed with the -jar option. We generally don't do that in Fedora. Does this mean Class-Path is still unacceptable? It's just that I found it extremely usable in the past.
What are the alternatives?
I built an application using Maven, and it uses the default <type>bundle</type> dependency, so Maven copies the class files of the dependencies into the application JAR. As a result, the JAR just works, but this is like static linking, with all its problems. Curiously, the Fedora packaging guidelines do not discuss this at all, as far as I can tell.
The spec file is here:
https://github.com/victims/victims-client-java/blob/master/victims-client-java.spec
As you can see, I use the usual Maven packaging framework.
----- Original Message -----
From: "Florian Weimer" fweimer@redhat.com To: "Andrew Haley" aph@redhat.com Cc: "java-devel" java-devel@lists.fedoraproject.org Sent: Thursday, February 6, 2014 1:19:22 PM Subject: Re: [fedora-java] Why no Class-Path manifest attribute?
On 05/29/2013 11:30 AM, Andrew Haley wrote:
On 05/29/13 10:13, Florian Weimer wrote:
The existence of the Class-Path attribute is not widely known, and I was surprised to see it mentioned in the policy.
Yes it is, it's very well-known, and is almost universally rejected. It bakes hard paths into jarfiles and overrides -classpath. In other words, it has similar disadvantages to -RPATH.
I finally experimented with this:
https://github.com/fweimer/classpath-manifest-override
The gist appears to be that overriding Class-Path entries is possible if the main class is not executed with the -jar option. We generally don't do that in Fedora. Does this mean Class-Path is still unacceptable? It's just that I found it extremely usable in the past.
What are the alternatives?
I built an application using Maven, and it uses the default <type>bundle</type> dependency, so Maven copies the class files of the dependencies into the application JAR. As a result, the JAR just works, but this is like static linking, with all its problems. Curiously, the Fedora packaging guidelines do not discuss this at all, as far as I can tell.
The spec file is here:
https://github.com/victims/victims-client-java/blob/master/victims-client-java.spec
As you can see, I use the usual Maven packaging framework.
Bundling (and this is what your example is) is entirely forbidden - not just for Java but for everything.
https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries
Do we need to add special link to that page in java guidelines? I don't think that adding links to all the generic guidelines would make the java one better it would just make it bigger and harder to digest.
Alexander Kurtakov Red Hat Eclipse team
-- Florian Weimer / Red Hat Product Security Team -- java-devel mailing list java-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/java-devel
On 02/06/2014 12:34 PM, Aleksandar Kurtakov wrote:
The spec file is here:
https://github.com/victims/victims-client-java/blob/master/victims-client-java.spec
As you can see, I use the usual Maven packaging framework.
Bundling (and this is what your example is) is entirely forbidden - not just for Java but for everything.
https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries
Even though Maven calls this dependency type "bundle", it is not bundling in the sense of the quoted page. The *sources* do not contain copies of the library dependencies, neither in source form nor as compiled classes. The guidelines cited above deal with what is contained in source RPMs—it does not even mention static linking.
Do we need to add special link to that page in java guidelines? I
don't think that adding links to all the generic guidelines would make the java one better it would just make it bigger and harder to digest.
I see two problems: The guidelines do not explicitly deal with copying class files between JARs (jarjar would be another option in this space). Contrast this with static linking, which is covered here:
https://fedoraproject.org/wiki/Packaging:Guidelines#Statically_Linking_Executables
The other aspect is that the maven-local tools silently create applications which are not complying with this (implicit so far) policy.
On 02/06/2014 12:54 PM, Florian Weimer wrote:
On 02/06/2014 12:34 PM, Aleksandar Kurtakov wrote:
The spec file is here:
https://github.com/victims/victims-client-java/blob/master/victims-client-java.spec
As you can see, I use the usual Maven packaging framework.
Bundling (and this is what your example is) is entirely forbidden - not just for Java but for everything.
https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries
Even though Maven calls this dependency type "bundle", it is not bundling in the sense of the quoted page. The *sources* do not contain copies of the library dependencies, neither in source form nor as compiled classes. The guidelines cited above deal with what is contained in source RPMs—it does not even mention static linking.
Do we need to add special link to that page in java guidelines? I
don't think that adding links to all the generic guidelines would make the java one better it would just make it bigger and harder to digest.
I see two problems: The guidelines do not explicitly deal with copying class files between JARs (jarjar would be another option in this space). Contrast this with static linking, which is covered here:
https://fedoraproject.org/wiki/Packaging:Guidelines#Statically_Linking_Executables
The other aspect is that the maven-local tools silently create applications which are not complying with this (implicit so far) policy.
maven-local builds packages using upstream POMs. If they are using techniques inappropriate for Fedora (like maven-jajjar-plugin, maven-shade-plugin, maven-assembly-plugin) then its packager responsibility to modify POMs in %prep so that they conform to our policy and standards. There are even specialised RPM macros to help with that (for example %pom_remove_plugin, see man pom_remove_plugin).
Besides that maven-local has support for blacklists, for example you can globally exclude maven-jajjar-plugin from all builds. That's only matter of agreeing on list of excluded plugins and adding appropriate config entry.
On 02/06/2014 01:04 PM, Mikolaj Izdebski wrote:
maven-local builds packages using upstream POMs. If they are using techniques inappropriate for Fedora (like maven-jajjar-plugin, maven-shade-plugin, maven-assembly-plugin) then its packager responsibility to modify POMs in %prep so that they conform to our policy and standards. There are even specialised RPM macros to help with that (for example %pom_remove_plugin, see man pom_remove_plugin).
Is maven-assembly-plugin really wrong, assuming that dependencies have a "provided" scope? I'm adding <scope>provided</scope> like this during the %prep stage, and appears to prevent copying over classes:
# Do not bundle dependencies in the generated JAR file. %pom_xpath_inject "/pom:project/pom:dependencies/pom:dependency[./pom:artifactId = 'victims-lib' or ./pom:artifactId = 'maven-model']" "<scope>provided</scope>"
Now I only need to figure out a way to auto-generate the dependencies and the classpath entries for %jpackage_script. This will not completely fix things (because the JAR list will still break encapsulation), but it will remove a lot of the pain.
On 02/06/2014 05:12 PM, Florian Weimer wrote:
On 02/06/2014 01:04 PM, Mikolaj Izdebski wrote:
maven-local builds packages using upstream POMs. If they are using techniques inappropriate for Fedora (like maven-jajjar-plugin, maven-shade-plugin, maven-assembly-plugin) then its packager responsibility to modify POMs in %prep so that they conform to our policy and standards. There are even specialised RPM macros to help with that (for example %pom_remove_plugin, see man pom_remove_plugin).
Is maven-assembly-plugin really wrong, assuming that dependencies have a "provided" scope? I'm adding <scope>provided</scope> like this during the %prep stage, and appears to prevent copying over classes:
# Do not bundle dependencies in the generated JAR file. %pom_xpath_inject "/pom:project/pom:dependencies/pom:dependency[./pom:artifactId = 'victims-lib' or ./pom:artifactId = 'maven-model']" "<scope>provided</scope>"
Modifying upstream POM files changing dependency scope to "provided" is purely wrong in many cases as such POMs won't be usable to build other packages.
Maven Assembly Plugin can generate assembles with dependencies with any scope you want. By default it's "runtime", but that's just a matter of configuration.
Now I only need to figure out a way to auto-generate the dependencies and the classpath entries for %jpackage_script. This will not completely fix things (because the JAR list will still break encapsulation), but it will remove a lot of the pain.
Transitive dependencies aren't handled automatically by %jpackage_script for a good reason -- often they are very excessive. Maven not only offers many dependency scopes, but allows optional dependencies and it's practically impossible to generate the proper classpath. Packager needs to do that manually.
It might be possible to generate classpath and allow packagers to exclude unwanted dependencies, but that's a future feature. You would need to file a RFE for javapackages-tools.
----- Original Message -----
From: "Florian Weimer" fweimer@redhat.com To: "Aleksandar Kurtakov" akurtako@redhat.com Cc: "Andrew Haley" aph@redhat.com, "java-devel" java-devel@lists.fedoraproject.org Sent: Thursday, February 6, 2014 1:54:12 PM Subject: Re: [fedora-java] Why no Class-Path manifest attribute?
On 02/06/2014 12:34 PM, Aleksandar Kurtakov wrote:
The spec file is here:
https://github.com/victims/victims-client-java/blob/master/victims-client-java.spec
As you can see, I use the usual Maven packaging framework.
Bundling (and this is what your example is) is entirely forbidden - not just for Java but for everything.
https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries
Even though Maven calls this dependency type "bundle", it is not bundling in the sense of the quoted page. The *sources* do not contain copies of the library dependencies, neither in source form nor as compiled classes. The guidelines cited above deal with what is contained in source RPMs—it does not even mention static linking.
I make perfect difference between bundle and bundling. What maven does is bundling libraries which is even against OSGi (what this is supposed to be) best practices. The fact that something is not in the source tarball but ends up in the final jar doesn't mean it's not bundled library, there are way too many ways to bundle to try getting a listing of them all.
From the problems listed on this page your example has - Security, Bugfixes and Old Code categories of problems present which makes it perfectly fit into the same category. Not to mention what problem such packages cause to OSGi containers when people abuse maven bundle plugin to make it easy by totally unrelated OSGi bundles start to expose similar things to the container (in your case victims-client-java exposing maven-model).
No matter what would one say/think/decide about using Class-Path (I don't have strong opinion on it) using bundle plugin in the way you propose is recipe for disaster and we already fixed way too many problems in many packages caused by abusing of maven-bundle-plugin. It should *ONLY* be used when one knows that he wants to make an OSGi bundle and thus consider the effect his change would have on OSGi containers.
Alexander Kurtakov Red Hat Eclipse Team
Do we need to add special link to that page in java guidelines? I
don't think that adding links to all the generic guidelines would make the java one better it would just make it bigger and harder to digest.
I see two problems: The guidelines do not explicitly deal with copying class files between JARs (jarjar would be another option in this space). Contrast this with static linking, which is covered here:
https://fedoraproject.org/wiki/Packaging:Guidelines#Statically_Linking_Executables
The other aspect is that the maven-local tools silently create applications which are not complying with this (implicit so far) policy.
-- Florian Weimer / Red Hat Product Security Team
On 02/06/2014 11:54 AM, Florian Weimer wrote:
On 02/06/2014 12:34 PM, Aleksandar Kurtakov wrote:
The spec file is here:
https://github.com/victims/victims-client-java/blob/master/victims-client-java.spec
As you can see, I use the usual Maven packaging framework.
Bundling (and this is what your example is) is entirely forbidden - not just for Java but for everything.
https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries
Even though Maven calls this dependency type "bundle", it is not bundling in the sense of the quoted page. The *sources* do not contain copies of the library dependencies, neither in source form nor as compiled classes. The guidelines cited above deal with what is contained in source RPMs—it does not even mention static linking.
I don't concur with your interpretation of that document.
It says that you can't bundle copies of libraries in packages. Source RPMs are irrelevant here, as is static linking.
Andrew.
On 02/06/2014 12:19 PM, Florian Weimer wrote:
On 05/29/2013 11:30 AM, Andrew Haley wrote:
On 05/29/13 10:13, Florian Weimer wrote:
The existence of the Class-Path attribute is not widely known, and I was surprised to see it mentioned in the policy.
Yes it is, it's very well-known, and is almost universally rejected. It bakes hard paths into jarfiles and overrides -classpath. In other words, it has similar disadvantages to -RPATH.
I finally experimented with this:
https://github.com/fweimer/classpath-manifest-override
The gist appears to be that overriding Class-Path entries is possible if the main class is not executed with the -jar option. We generally don't do that in Fedora. Does this mean Class-Path is still unacceptable? It's just that I found it extremely usable in the past.
What are the alternatives?
The alternative is installing a wrapper script in /usr/bin, which will take care of constructing appropriate classpath. This way users don't need to invoke java manually. They don't even need to know that the software is written in Java.
Many upstream projects provide shell scripts you can install directly. Even if they don't, you can generate and install such script %jpackage_script macro, which is documented in Java guidelines.
I built an application using Maven, and it uses the default <type>bundle</type> dependency, so Maven copies the class files of the dependencies into the application JAR. As a result, the JAR just works, but this is like static linking, with all its problems. Curiously, the Fedora packaging guidelines do not discuss this at all, as far as I can tell.
Bundling is forbidden and I am pretty sure it is well explained in the packaging guidelines.
On 02/06/2014 12:43 PM, Mikolaj Izdebski wrote:
The alternative is installing a wrapper script in /usr/bin, which will take care of constructing appropriate classpath. This way users don't need to invoke java manually. They don't even need to know that the software is written in Java.
Many upstream projects provide shell scripts you can install directly. Even if they don't, you can generate and install such script %jpackage_script macro, which is documented in Java guidelines.
Thanks for the suggestion. Is there a way to automate gathering all the dependencies? Maven should already have all this information.
But doing this at compile time is wrong because at run time, the dependencies might have changed, and hard-coding the compile-time set breaks encapsulation.
On 02/06/2014 05:43 AM, Mikolaj Izdebski wrote:
On 02/06/2014 12:19 PM, Florian Weimer wrote:
On 05/29/2013 11:30 AM, Andrew Haley wrote:
On 05/29/13 10:13, Florian Weimer wrote:
The existence of the Class-Path attribute is not widely known, and I was surprised to see it mentioned in the policy.
Yes it is, it's very well-known, and is almost universally rejected. It bakes hard paths into jarfiles and overrides -classpath. In other words, it has similar disadvantages to -RPATH.
I finally experimented with this:
https://github.com/fweimer/classpath-manifest-override
The gist appears to be that overriding Class-Path entries is possible if the main class is not executed with the -jar option. We generally don't do that in Fedora. Does this mean Class-Path is still unacceptable? It's just that I found it extremely usable in the past.
What are the alternatives?
The alternative is installing a wrapper script in /usr/bin, which will take care of constructing appropriate classpath. This way users don't need to invoke java manually. They don't even need to know that the software is written in Java.
Many upstream projects provide shell scripts you can install directly. Even if they don't, you can generate and install such script %jpackage_script macro, which is documented in Java guidelines.
There is another alternative. The modular runtime [1] we use for WildFly and JBoss EAP can actually support any application that normally runs with a flat class path. Basically it allows you to have the Java equivalent of a lib/ directory for all JARs, while specifying the exact linkage between those JARs in external dependency files. We anticipate that this will be functionally similar to the modularity proposal which is currently targeted for Java 9.
If your ultimate goal is to provide one giant set of maximally intercompatible JARs in Fedora, then this is your best bet for it.
[1] https://docs.jboss.org/author/display/MODULES/Home
On 02/06/2014 03:05 PM, David M. Lloyd wrote:
If your ultimate goal is to provide one giant set of maximally intercompatible JARs in Fedora, then this is your best bet for it.
My goal is to be compatible with existing packaged Java libraries in Fedora, such as h2, google-gson, plexus-utils, and their dependencies.
Would JBoss Modules achieve that?
On 02/06/2014 08:11 AM, Florian Weimer wrote:
On 02/06/2014 03:05 PM, David M. Lloyd wrote:
If your ultimate goal is to provide one giant set of maximally intercompatible JARs in Fedora, then this is your best bet for it.
My goal is to be compatible with existing packaged Java libraries in Fedora, such as h2, google-gson, plexus-utils, and their dependencies.
Would JBoss Modules achieve that?
I have successfully run many things within JBoss Modules, including H2 enough to believe that any classpath-based application should be able use it. I have even run Maven with it, though I don't think I've directly tried plexus-utils, or google-gson, however I would expect it to work just fine. We run over 300 different libraries with this runtime, most of which were not written with anything but classpath in mind.
As for packaging, JBoss Modules does have a default a file system layout it uses, though that is pluggable if you want to follow a different convention. The only requirement is that the dependency specifications should be able to specify exactly where/how to find each dependency (i.e. without having to scan the filesystem for example). The default mechanism uses dot-separated names (e.g. "com.h2database.h2"), decomposes them into a relative path ("com/h2database/h2"), and looks at that path relative to the module root to find the module file and content.
There is also a mechanism to support platform-specific native libraries.
java-devel@lists.fedoraproject.org
-
Aleksandar Kurtakov -
Andrew Dinn -
Andrew Haley -
David M. Lloyd -
David Walluck -
Florian Weimer -
Jiri Vanek -
Mat Booth -
Mikolaj Izdebski -
Stanislav Ochotnicky