2018-06-07 10:27 GMT+02:00 Gábor Boskovits : > 2018-06-07 9:20 GMT+02:00 Ricardo Wurmus : > >> >> Danny Milosavljevic 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 >> >> >> >> >