GNU bug report logs - #31721
“generate-jar-indices” phase fails on many packages

Previous Next

Full log

Message #14 received at 31721 <at> debbugs.gnu.org (full text, mbox):

From: Gábor Boskovits <boskovits <at> gmail.com>
To: Ricardo Wurmus <ricardo.wurmus <at> mdc-berlin.de>
Cc: Danny Milosavljevic <dannym <at> scratchpost.org>, 31721 <at> debbugs.gnu.org
Subject: Re: bug#31721: “generate-jar-indices” phase fails on many packages
Date: Thu, 7 Jun 2018 10:46:41 +0200

[Message part 1 (text/plain, inline)]

2018-06-07 10:27 GMT+02:00 Gábor Boskovits <boskovits <at> gmail.com>:

> 2018-06-07 9:20 GMT+02:00 Ricardo Wurmus <ricardo.wurmus <at> mdc-berlin.de>:
>
>>
>> Danny Milosavljevic <dannym <at> 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.
>
> This is what is in build.gradle:
dependencies {
compile('com.intel.gkl:gkl:0.8.5') {
exclude module: 'htsjdk'
}
 So we should exclude htsjdk module from gkl when building java-picard.
Do we have a method to do that easily?


>
>> >> or about missing files as in dropseq-tools:
>> >>
>> >>     java.io.FileNotFoundException: /gnu/store/q76y0ximcziplgfpbn2
>> 6kbw4h3s14f33-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
>>
>>
>>
>>
>

[Message part 2 (text/html, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.