“generate-jar-indices” phase fails on many packages

  • Open
  • quality assurance status badge
Details
2 participants
  • Gábor Boskovits
  • Ricardo Wurmus
Owner
unassigned
Submitted by
Ricardo Wurmus
Severity
normal
R
R
Ricardo Wurmus wrote on 5 Jun 2018 13:15
(address . bug-guix@gnu.org)(name . Danny Milosavljevic)(address . dannym@scratchpost.org)
8736y11o2q.fsf@mdc-berlin.de
The “generate-jar-indices” phase fails on a couple of packages, such as

java-picard (all variants)
dropseq-tools
java-cisd-jhdf5

The errors are either about duplicates as in java-picard-2.10.3:

duplicate entry: htsjdk/samtools/AbstractBAMFileIndex$1.class

or about missing files as in dropseq-tools:

java.io.FileNotFoundException: /gnu/store/q76y0ximcziplgfpbn26kbw4h3s14f33-dropseq-tools-1.13/share/java/lib/biojava-alignment.jar

I have removed the phase in these packages, but that’s not ideal.

Can we make this phase more robust?

--
Ricardo
R
R
Ricardo Wurmus wrote on 7 Jun 2018 09:20
(name . Danny Milosavljevic)(address . dannym@scratchpost.org)(address . 31721@debbugs.gnu.org)
877enbyse2.fsf@elephly.net
Danny Milosavljevic <dannym@scratchpost.org> writes:

Toggle quote (7 lines)
>> 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?

Toggle quote (6 lines)
>> 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.

Toggle quote (8 lines)
> 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
G
G
Gábor Boskovits wrote on 7 Jun 2018 10:27
Re: bug#31721: “generate-jar-indices” phase fail s on many packages
(name . Ricardo Wurmus)(address . ricardo.wurmus@mdc-berlin.de)
CAE4v=pitxJ_W3M1uacrGqAEg-NG7V1XaD+iSFJ-o7Kg4rXtq8A@mail.gmail.com
2018-06-07 9:20 GMT+02:00 Ricardo Wurmus <ricardo.wurmus@mdc-berlin.de>:

Toggle quote (14 lines)
>
> 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.



Toggle quote (31 lines)
> >> 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
>
>
>
>
Attachment: file
G
G
Gábor Boskovits wrote on 7 Jun 2018 10:46
(name . Ricardo Wurmus)(address . ricardo.wurmus@mdc-berlin.de)
CAE4v=pgfxpP9pSu8exKnYAxJa4-_dvOh_QARLZD6Vs6Xs=TXdw@mail.gmail.com
2018-06-07 10:27 GMT+02:00 Gábor Boskovits <boskovits@gmail.com>:

Toggle quote (25 lines)
> 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.
>
> 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?


Toggle quote (33 lines)
>
>> >> 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
>>
>>
>>
>>
>
Attachment: file
?