2018-06-07 10:27 GMT+02:00 Gábor Boskovits <email@example.com>:
Toggle quote (25 lines)
> 2018-06-07 9:20 GMT+02:00 Ricardo Wurmus <firstname.lastname@example.org>:
>> Danny Milosavljevic <email@example.com> 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
>> > 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
> 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
> This is what is in build.gradle:
exclude module: 'htsjdk'
So we should exclude htsjdk module from gkl when building java-picard.
Do we have a method to do that easily?
Toggle quote (33 lines)
>> >> 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
>> 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
>> > before invoking "jar -i".
>> > Then "jar -i" will index those - and all java packages can use regular
>> > 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?