bug#31721: “generate-jar-indices” phase fails on many packages

[Gábor Boskovits]

2018-06-07 10:27 GMT+02:00 Gábor Boskovits <address@hidden>:

2018-06-07 9:20 GMT+02:00 Ricardo Wurmus <address@hidden>:

Danny Milosavljevic <address@hidden> writes:

>> The errors are either about duplicates as in java-picard-2.10.3:
>>
>>     duplicate entry: htsjdk/samtools/AbstractBAMFileIndex$1.class
>
> That's... bad.  What if those files differed?  Which one would be used at
> runtime?

I wonder where they come from.  Is this from a dependency or are there
actually two such classes?

Is it possible that these come from a package, where a renamed dependency is

used in the original build system, thus avoiding the name duplication? I will have a

look at this package source... Will report back if I can confirm this assumption.

This is what is in build.gradle:

dependencies {
	compile('com.intel.gkl:gkl:0.8.5') {
	exclude module: 'htsjdk'
	}

 So we should exclude htsjdk module from gkl when building java-picard.

Do we have a method to do that easily?

 

>> or about missing files as in dropseq-tools:
>>
>>     java.io.FileNotFoundException: /gnu/store/q76y0ximcziplgfpbn26kbw4h3s14f33-dropseq-tools-1.13/share/java/lib/biojava-alignment.jar
>
> That's also bad.  How does it run at all if its dependencies are missing?

To satisfy the dropseq-tools build system the dependencies a symlinked
to the build directory.  I suspect that the error is something to do
with that.

> The only thing I can think of that would improve things long term:
>
> The phase can add relative paths to all the dependencies to META-INF/MANIFEST.MF
> before invoking "jar -i".
> Then "jar -i" will index those - and all java packages can use regular inputs
> instead of propagated inputs.  I've tested that locally already - and it
> works fine.

Is it correct that this would ensure that in case of duplicate class
names this would pick the class from the current package?

--
Ricardo