“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
?
Your comment

Commenting via the web interface is currently disabled.

To comment on this conversation send an email to 31721@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 31721
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch