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