|
From: | Gábor Boskovits |
Subject: | bug#31721: “generate-jar-indices” phase fails on many packages |
Date: | Thu, 7 Jun 2018 10:46:41 +0200 |
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 isused in the original build system, thus avoiding the name duplication? I will have alook at this package source... Will report back if I can confirm this assumption.
dependencies { | |
compile('com.intel.gkl:gkl:0.8.5') { | |
exclude module: 'htsjdk' | |
} |
>> or about missing files as in dropseq-tools:
>>
>> java.io.FileNotFoundException: /gnu/store/q76y0ximcziplgfpbn2 > That's also bad. How does it run at all if its dependencies are missing?6kbw4h3s14f33-dropseq-tools-1. 13/share/java/lib/biojava- alignment.jar
>
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
[Prev in Thread] | Current Thread | [Next in Thread] |