[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: status on picard-tools and issue with libsnappy-java

On Mon, Aug 13, 2012 at 09:27:50AM +0200, olivier.sallou@codeless.fr wrote:
> I copy below the answer from upstream team.
> They will not go to latest snappy version. Seems it was quite difficult
> to integrate it and faced issues.
> The problem is snappy-java 1.0.4 breaks its API and is not compatible
> with version 1.0.3 used by picard-tools.

This is what we also learned (the hard way).
> At runtime, picard-tools tries to detect snappy. If not present, it will
> be ok. However we still face the problem for Debian for compilation....
> -------- Message original --------
> Sujet: 	Re: [Samtools-help] support of snappy-1.0.4
> Date : 	Thu, 09 Aug 2012 10:27:11 -0400
> De : 	Alec Wysoker <alecw@broadinstitute.org>
> Pour : 	olivier.sallou <olivier.sallou@laposte.net>
> Copie à : 	samtools-help@lists.sourceforge.net
> ...
> Could you try one of the following alternatives to using latest snappy-java:
>   * Use the same version Picard uses, i.e. 1.0.3-rc3

It somehow came to my mind to package this older version.  Finally we
started packaging libsnappy-java for the only purpose to support picard
... and currently this purpose is not fullfilled.

>   * Omit snappy-java classes completely. 
>     net.sf.samtools.util.SnappyLoader is written so that if
>     org.xerial.snappy.SnappyInputStream and
>     org.xerial.snappy.SnappyOutputStream are not found on the classpath,
>     then the code should work without using Snappy.

Hmmm, I do not know the advantage we would liked to reach and whether
this is acceptable.  However,  it seems to make sense to do not only a
check whether the class is available but also to verify the version if
there are incompatible versions known.  I have no idea whether this is
possible - but if yes this would be a reasonable hint to upstream.

Kind regards



Reply to: