Combining these two threads and my previous one on auto-generating Depends: lines, I'd like to propose a new policy and a couple of new tools (which, conveniently, I've already written).
The policy I would like to see added is that all jar files should have a correct Class-Path manifest entry containing all required jars (excluding, of course, what's expected to be in the VM by default). This would then allow several things as a consequence. Applications could be run with just java -jar $jar; the recursive Class-Path from the jar files would construct the correct classpath. This in turn allows the use of binfmt-misc to run them through a wrapper which doesn't need to know the classpath, rather than a custom wrapper for each application. This leads onto the first tool, which is jarwrapper and the appropriate magic to make it work via binfmt-misc. I have written and packaged this, and it is available at http://mjj29.matthew.ath.cx/debian-upload/jarwrapper/ Any application supplying executable jars would have to depend on this. I think policy should say that executable jars should still be installed into /usr/share/java, but symlinked to /usr/bin (they may be both an executable jar and a jar needed by a separate executable jar). The second thing which this enables (as I mentioned in a previous thread) is a way to generate dependencies on other jar files automatically. Thus, the second tool is dh_jardeps, which would find all the jars in your package, read out the Class-Path field and add the package containing each jar to the substvars for that package and if any of them were executable add jarwrapper. I have written a sample implementation of this at http://mjj29.matthew.ath.cx/dh_jardeps You might argue that it is as much work to add Class-Path to jars as dependencies to the control file, but dh_jardeps would mean only doing it once and ideally the Class-Path generation would be pushed to upstream; in which case packagers have to do neither. Lastly, given the executable jars a modification would have to be made to lintian so that it would not complain. What do people think? Matt -- Matthew Johnson
signature.asc
Description: Digital signature
