[Debian-med-packaging] [rt.broad #134078] Packaging IGV for Debian [PATCH]

Shaun Jackman sjackman at gmail.com
Fri Jun 18 00:00:03 UTC 2010 

Hi James,

I've removed support for MAF files from IGV. It was very straight
forward and only required modifying to Java files and the build.xml
file. Getting closer... the list of unresolved dependencies is now:

AbsoluteLayout.jar	netbeans-platform
jlfgr-1_0.jar	http://java.sun.com/developer/techDocs/hi/repository/
ledatastream.jar	http://mindprod.com/products1.html#LEDATASTREAM
colt.jar	http://acs.lbl.gov/software/colt/
JIDE	http://www.jidesoft.com/

Cheers,
Shaun

On 17 June 2010 11:15, James Robinson via RT
<igv-help at broadinstitute.org> wrote:
> Yes, removing support is an option,  its only used for the UCSC human
> multiple alignments track,  a very rarely used option.
>
> ledatastream.jar comes from here
>
> http://mindprod.com/products1.html#LEDATASTREAM
>
>
>
> On Jun 17, 2010, at 2:02 PM, Shaun Jackman via RT wrote:
>
>>
>> <URL: https://rt.broadinstitute.org/Ticket/Display.html?id=134078 >
>>
>> Hi Jim,
>>
>> Debian is divided up into its main repository and a non-free
>> repository. Without source code, maf.jar could be packaged in the
>> non-free repository, but it's definitely preferred to have the source
>> code. Packaging other libraries requires additional work that would
>> delay getting IGV into Debian. In the mean time, I could remove
>> support for the MAF file format from IGV. Looking at
>> TrackManager.java(load), it would be straight forward.
>>
>> That leaves ledatastream.jar and colt.jar to be resolved. I'll talk to
>> the Debian-Java packaging team and see if they would be interested in
>> packaging Colt.
>>
>> Cheers,
>> Shaun
>>
>> On 16 June 2010 17:32, James Robinson via RT
>> <igv-help at broadinstitute.org> wrote:
>>> Hi,
>>>
>>> I'll look into a netbeans 6 port but it will be post release 1.5,
>>> everything has gone through tests and is ready for release and I
>>> don't
>>> have time to go thought that process again.   Do you really have to
>>> have source to do a debian package?   The developer of maf.jar is
>>> very
>>> busy and no its not actively maintained as a separate jar,  I
>>> carefully carved that out from the predecessor to siphy.   The siphy
>>> route might be the only option if you must have source.
>>>
>>> Jim
>>>
>>>
>>> On Jun 16, 2010, at 8:24 PM, Shaun Jackman via RT wrote:
>>>
>>>>
>>>> <URL: https://rt.broadinstitute.org/Ticket/Display.html?id=134078 >
>>>>
>>>> Hi Jim,
>>>>
>>>> For AbsoluteLayout, NetBeans version 6 doesn't seem to provide
>>>> AbsoluteConstraints. I know naught about NetBeans, but it looks as
>>>> though you're meant to use the member functions
>>>> childWidget.getPreferredLocation and childWidget.getPreferredBounds
>>>> rather than AbsoluteConstraints:
>>>> http://bits.netbeans.org/dev/javadoc/org-netbeans-api-visual/org/netbeans/api/visual/widget/doc-files/documentation.html#AbsoluteLayout
>>>>
>>>> Would you be able to port IGV to NetBeans 6?
>>>>
>>>> For maf.jar, I'd need the source code (and its license) to be able
>>>> to
>>>> package it for Debian. It would be best if I had a web page that I
>>>> could point to, but it's not strictly necessary. An e-mail address
>>>> of
>>>> a contact would be good. Is maf.jar still actively maintained?
>>>>
>>>> Cheers,
>>>> Shaun
>>>>
>>>> On 16 June 2010 16:08, James Robinson via RT
>>>> <igv-help at broadinstitute.org> wrote:
>>>>> I'm very involved in the HDF5 discussion and with Dana Robinson
>>>>> behind
>>>>> the scenes.   Heng Li and I will be meeting Dana when he's in
>>>>> Boston
>>>>> next month.  We're going to collaborate on IGV support for their
>>>>> alignment format.   I doubt very much that there will be any
>>>>> significant performance advantage over BAM when the full spec is
>>>>> supported,  but I'm neutral on this and will support both if/when
>>>>> they
>>>>> have something.
>>>>>
>>>>> TDF is IGV's binary format,   similar to bigWIG but it supports
>>>>> more
>>>>> formats (all the IGV formats).
>>>>>
>>>>> The main reason for the port was (1) performance, and (2) the
>>>>> lack of
>>>>> pure java readers.  The performance issue has to do with the
>>>>> details
>>>>> of the hierarchical data model IGV uses,  HDF5 wasn't a good fit.
>>>>> The lack of native java support was significant,  requiring JNI and
>>>>> builds for every OS / Architecture combination,  basically an
>>>>> intractable problem for a platform independent tool like IGV.   It
>>>>> negated Java's advantage in that regard.
>>>>>
>>>>> RE AbsoluteLayout,  that should be compatible,  its probably just a
>>>>> later version of the jar I'm using.    You are free to package
>>>>> maf.jar,  do you need a webpage or reference to do that?  Its an
>>>>> internal library used here,  it doesn't have a webpage and probably
>>>>> never will.
>>>>>
>>>>> Jim
>>>>>
>>>>>
>>>>>
>>>>> On Jun 16, 2010, at 6:05 PM, Shaun Jackman via RT wrote:
>>>>>
>>>>>>
>>>>>> <URL: https://rt.broadinstitute.org/Ticket/Display.html?
>>>>>> id=134078 >
>>>>>>
>>>>>> Hi James,
>>>>>>
>>>>>> What is TDF? I haven't heard of it. Why did you migrate from HDF5?
>>>>>> There's a discussion on the samtools mailing list right now about
>>>>>> whether BAM should be adapted to HDF5. HDF5 is in Debian. So it's
>>>>>> not
>>>>>> an issue.
>>>>>>
>>>>>> Debian does have batik (libbatik-java), so that's good.
>>>>>>
>>>>>> The Debian package netbeans-platform contains a class named
>>>>>> AbsoluteLayout
>>>>>> org.netbeans.modules.visual.layout.AbsoluteLayout
>>>>>> Do you know whether this class would be compatible with IGV? It's
>>>>>> in a
>>>>>> different package than the one used by IGV:
>>>>>> org.netbeans.lib.awtextra.AbsoluteLayout
>>>>>>
>>>>>> maf.jar seems to be included with siphy, but I couldn't find a web
>>>>>> page for just maf.jar. Does it have a web page? I'd rather just
>>>>>> package maf.jar rather than all of siphy.
>>>>>>
>>>>>> Cheers,
>>>>>> Shaun
>>>>>>
>>>>>> On 16 June 2010 11:10, James Robinson via RT
>>>>>> <igv-help at broadinstitute.org> wrote:
>>>>>>>
>>>>>>> Hi Shaun,
>>>>>>>
>>>>>>> Thanks for doing this work!  And also for the H5 tip.   I'll
>>>>>>> include
>>>>>>> this change in the upcoming 1.5 release (early next week).   HDF5
>>>>>>> is
>>>>>>> included only for legacy purposes,  and will be dropped soon,
>>>>>>> probably in the release after 1.5.   Originally that was the IGV
>>>>>>> binary format but it was replaced by TDF a year ago.
>>>>>>>
>>>>>>> The components you mention are neccessary,  AbsoluteLayout.jar is
>>>>>>> used
>>>>>>> for window layouts,  colt.jar is used for computing percentiles,
>>>>>>> ledatastream is used for reading little-endian file formats,
>>>>>>> including TDF,  and maf.jar is used for reading multiple
>>>>>>> alignment
>>>>>>> files.  The maf.jar file is from another group here at the Broad.
>>>>>>>
>>>>>>> In 1.5 I have dropped jibble.jar in favor of the apache-commons
>>>>>>> "batik" package (http://xmlgraphics.apache.org/batik/).   The bad
>>>>>>> news
>>>>>>> is there is a slew of jars included with this package.   Do you
>>>>>>> know
>>>>>>> if its part of the debian distribution?
>>>>>>>
>>>>>>> Jim
>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> I'm interested in packaging IGV for Debian as part of the Debian
>>>>>>>> Med
>>>>>>>> project. Resolving the dependencies of IGV is ongoing work, but
>>>>>>>> many
>>>>>>>> of the dependencies are already packaged for Debian. These
>>>>>>>> dependencies are unresolved:
>>>>>>>> AbsoluteLayout.jar
>>>>>>>> colt.jar
>>>>>>>> JIDE
>>>>>>>> ledatastream.jar
>>>>>>>> maf.jar
>>>>>>>>
>>>>>>>> Could you comment on whether each of these is a necessary
>>>>>>>> component of
>>>>>>>> IGV, or which could potentially be removed?
>>>>>>>>
>>>>>>>> Debian does not package Jibble, but it does package the GPL-
>>>>>>>> licensed
>>>>>>>> jlibeps, which is a drop-in replacement:
>>>>>>>> http://jlibeps.sourceforge.net/
>>>>>>>>
>>>>>>>> A single line change is needed for the source code to use
>>>>>>>> jlibeps.
>>>>>>>> See
>>>>>>>> the patch following this e-mail.
>>>>>>>>
>>>>>>>> I had trouble compiling this line:
>>>>>>>>    dataType = H5.H5Tcopy(H5.J2C(HDF5Constants.H5T_C_S1));
>>>>>>>>        After reading some HDF5 documentation, I found that it is
>>>>>>>> unnecessary to call J2C for a constant beginning with the prefix
>>>>>>>> H5,
>>>>>>>> as both the Java and C constant have the same value:
>>>>>>>> http://www.ssec.wisc.edu/visad-docs/javadoc/ncsa/hdf/hdf5lib/HDF5CDataTypes.html
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>> Shaun
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>
>
>

More information about the Debian-med-packaging mailing list