Re: broken references in jar manifests

["Gábor Boskovits" <boskovits@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1776 bytes --]

2018-03-01 18:11 GMT+01:00 Ricardo Wurmus <ricardo.wurmus@mdc-berlin.de>:

> Hi Guix,
>
> we have a problem with jar manifests.  When we use the Class-Path
> property to ensure that an executable can find its dependencies on the
> class path at run-time, we end up with a manifest like this:
>
> --8<---------------cut here---------------start------------->8---
> Manifest-Version: 1.0
> Class-Path: /gnu/store/i28vi94r8z9f0x02zgkrv87w16ibmqkw-java-htsjdk-2.
>  10.1/share/java/htsjdk.jar
> Created-By: 1.8.0_151 (Oracle Corporation)
> Main-Class: picard.cmdline.PicardCommandLine
> --8<---------------cut here---------------end--------------->8---
>
> Note that the Class-Path property is broken into two lines.  This means
> that the reference scanner will miss it and grafting will fail.
>
>
Could we modify the reference scanner to find these lines?
Would there be any serious drawback to that?


> Breaking up lines longer than 70 characters is according to the manifest
> specification, see
> https://docs.oracle.com/javase/7/docs/technotes/guides/jar/jar.html
>
> We cannot just use a wrapper that sets CLASSPATH, because it appears to
> be ignored when using a manifest with “Main-Class”.  “Main-Class” is
> required for executables that can be run like this:
>
>     java -jar whatever.jar
>
> A possible work-around might be to patch the class loader of our JDKs to
> look at a custom Guix-specific file, which we will include in each jar.
> That file would be allowed to have longer lines.
>
> There are two disadvantages:
>
> 1) we need to patch the JDK
> 2) the jars would not do the right thing when executed with a different
> JDK (e.g. on a foreign distro).
>
> What do you think?
>
> --
> Ricardo
>
>

[-- Attachment #2: Type: text/html, Size: 2490 bytes --]