Danny Milosavljevic <dan...@scratchpost.org> 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? >> 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
