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