2018-06-07 9:20 GMT+02:00 Ricardo Wurmus <[email protected]>:
> > Danny Milosavljevic <[email protected]> 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. > >> 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 > > > >
