2018-06-07 9:20 GMT+02:00 Ricardo Wurmus <ricardo.wurmus@mdc-berlin.de>:

>
> Danny Milosavljevic <dannym@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?
>
>
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
>
>
>
>