Hi Danny,
>> (The specification says that INDEX.LIST is preferred if it exists)
>
> Just tried "jar -i" with java-picard after manually editing the class
> path to be much longer:
[…]
> No wrapping done anywhere (I added ./././ to the manifest in order to
> make the line very long).
That’s great. Thanks for testing.
I’m still not clear on the effect of the INDEX.LIST file. According to
the specs it sounds like this could be used to set a search path for
classes:
When the classloader loads the root jar file, it reads the
INDEX.LIST file and uses it to construct a hash table of mappings
from file and package names to lists of jar file names. In order to
find a class or a resource, the class loader queries the hashtable
to find the proper jar file and then downloads it if necessary.
If this is really so we could turn all propagated-inputs into regular
inputs for all Java packages (in many cases they already are regular
inputs, but this may actually be a mistake).
We would have to test this in a real-world example, such as the
dropseq-tools package, which currently has an unsightly
“record-references” phase. If it is sufficient to record the Java
package inputs in an INDEX.LIST file, we should do this in the
ant-build-system.
--
Ricardo
GPG: BCA6 89B6 3655 3801 C3C6 2150 197A 5888 235F ACAC
https://elephly.net
