[ImageJ-devel] Problems uploading jars to update site

Fri Mar 20 11:11:08 CDT 2015

Hi Birgit,

[Switching to imagej-devel, to avoid spamming ImageJ users with technical
mumbo jumbo.]

>  the Xalan jar is included in our dependencies only to due loci_tools
>  declaring that jar as a dependency. As during the update procedure we
>  were also told that loci_tools is now part of the bioformats package,
>  I wonder if we can get rid of that dependency by switching from
>  loci_tools to bioformats_package.

>From a Maven perspective, I would suggest depending on the actual
Bio-Formats components you are using, rather than any uber-JAR such as
loci_tools (deprecated) or bioformats_package (the current uber-jar).

There is a brief discussion of the pros and cons of uber-jars from an
ImageJ perspective here:

http://imagej.net/Frequently_Asked_Questions#How_can_I_call_ImageJ_from_my_software.3F

If you point me at the public SCM for your project, I'll gladly take a look
at your POM and make some suggestions. With Bio-Formats, the standard
approach is to add compile-time dependency on ome:formats-api:5.0.8, and
runtime dependencies on ome:formats-bsd:5.0.8 and ome:formats-gpl:5.0.8,
since those latter two components provide file format implementations
("plugin"-esque) which are not needed at compile time, but you want on the
classpath at runtime for all the file format support.

Regards,
Curtis

On Fri, Mar 20, 2015 at 7:57 AM, Birgit Möller <
birgit.moeller at informatik.uni-halle.de> wrote:

> Hi Curtis!
>
> On Thu, 19 Mar 2015 12:37:30 -0500, Curtis Rueden <ctrueden at WISC.EDU>
> wrote:
> >Hi Birgit,
> >
> >> we are trying to set up an ImageJ update site for our plugin
> >> collection MiToBo.
> >
> >Sounds great!
> >
> >> Since we have a lot of dependencies we would like to test the setup
> >> first on our own local server
> >
> >Good idea.
> >
> >> but in the end we plan to provide Mitobo via an ImageJ Wiki update
> >> site.
> >
> >Well, if you have a dedicated server, you can just use that. There is no
> >requirement to use a personal update site. But I guess the URL "
> >http://sites.imagej.net/MiToBo" would be pretty friendly. :-)
>
> yes, I agree, and we will go for it soon :-)
>
> >> Amongst others we depend on two jars, sezpoz.jar and xalan.jar. Both
> >> jars seem to have been provided by the Fiji Update Site in former
> >> days, but are now declared obsolete.
> >
> >Indeed.
> >
> >> Since we need both of them we tried to upload them to our own site,
> >> however, this fails. First Fiji claims about changed checksums for
> >> both jar files. After recalculating the checksums and trying to
> >> upload them again, the updater throws the following exception:
> >>
> >> Upload failed: java.lang.NoClassDefFoundError:
> >> org/apache/xml/serializer/TreeWalker
> >
> >How bizarre. I wonder if this is something xalan-specific, since xalan
> >ships classes that are also part of the JRE itself. As a test, you could
> >temporarily delete your xalan JAR, restart ImageJ, and try to add _only_
> >the sezpoz JAR to your update site, and see whether you encounter the same
> >issue.
>
> It looks like it is really a Xalan issue. Skipping the Xalan jar
> everything works fine. Meanwhile I also figured out that the Xalan jar is
> included in our dependencies only to due loci_tools declaring that jar as a
> dependency. As during the update procedure we were also told that
> loci_tools is now part of the bioformats package, I wonder if we can get
> rid of that dependency by switching from loci_tools to bioformats_package.
> Moreover, if the Xalan jar is not present, our operators and plugins seem
> to work anyway, so maybe we even do not really need any stuff contained in
> that jar - but we will still need to investigate that further.
>
> >[...]
> >
> >Regards,
> >Curtis
> >
> >[...]
>
> For now, thanks for your elaborate reply.  If we encounter additional
> problems, I will get back to you and the list again. But, as suggested,
> next time I will post questions regarding update sites on the imagej-devel
> list instead of this one.
> Thanks and kind regards,
>
>  Birgit
>
> ---
>
> On Thu, 19 Mar 2015 12:37:30 -0500, Curtis Rueden <ctrueden at WISC.EDU>
> wrote:
>
> >Hi Birgit,
> >
> >> we are trying to set up an ImageJ update site for our plugin
> >> collection MiToBo.
> >
> >Sounds great!
> >
> >> Since we have a lot of dependencies we would like to test the setup
> >> first on our own local server
> >
> >Good idea.
> >
> >> but in the end we plan to provide Mitobo via an ImageJ Wiki update
> >> site.
> >
> >Well, if you have a dedicated server, you can just use that. There is no
> >requirement to use a personal update site. But I guess the URL "
> >http://sites.imagej.net/MiToBo" would be pretty friendly. :-)
> >
> >> Amongst others we depend on two jars, sezpoz.jar and xalan.jar. Both
> >> jars seem to have been provided by the Fiji Update Site in former
> >> days, but are now declared obsolete.
> >
> >Indeed.
> >
> >> Since we need both of them we tried to upload them to our own site,
> >> however, this fails. First Fiji claims about changed checksums for
> >> both jar files. After recalculating the checksums and trying to
> >> upload them again, the updater throws the following exception:
> >>
> >> Upload failed: java.lang.NoClassDefFoundError:
> >> org/apache/xml/serializer/TreeWalker
> >
> >How bizarre. I wonder if this is something xalan-specific, since xalan
> >ships classes that are also part of the JRE itself. As a test, you could
> >temporarily delete your xalan JAR, restart ImageJ, and try to add _only_
> >the sezpoz JAR to your update site, and see whether you encounter the same
> >issue.
> >
> >> What is Fiji's strategy to deal with cases where the same jar in
> >> different versions is provided by two update sites?
> >
> >IIRC, the ImageJ Updater (which is part of ImageJ2, and not specific to
> the
> >Fiji distribution) favors versions further down in the list of update
> >sites. That is: there is a linear order to the update sites, such that
> >files from sites further down the chain are considered to "shadow" the
> same
> >file from sites further up the chain. The reason I say "IIRC" is because I
> >am not 100% certain that chain order is only defined by the ordering
> listed
> >on the "List of update sites" wiki page. It may be that the order changes
> >for a local installation depending on when sites are toggled on and off.
> If
> >you are curious to dig in further, there is a unit test that verifies that
> >various multi-update-site features work properly [1], which you could play
> >with.
> >
> >The gist is that there is currently _no_ mechanism for defining
> >update-site-level dependencies, beyond just building on top of the ImageJ
> >and Fiji update sites. It is currently the user's responsibility to enable
> >update sites upon which your update site depends. Some day we may address
> >that issue as the number of update sites continues to grow, but it is not
> a
> >simple feature to add.
> >
> >> How does the updater try to determine depencies of plugins? In our
> >> case while checking our local jars it claimed to detect a cyclic
> >> dependency which was not there.
> >
> >It uses byte-code analysis to detect the dependencies. However, you can
> >tweak them before uploading by editing the list of dependencies directly
> in
> >the right-hand text box of the graphical updater window. This is sometimes
> >necessary in cases where there are undesired circular dependencies (e.g.,
> >slf4j-api and various slf4j bindings always detect as circular, due to the
> >design of SLF4J).
> >
> >Regards,
> >Curtis
> >
> >[1]
> >
> https://github.com/imagej/imagej-updater/blob/imagej-updater-0.7.1/src/test/java/net/imagej/updater/MultipleSitesTest.java
> >
> >On Sun, Mar 15, 2015 at 7:34 AM, Birgit Möller <
> >birgit.moeller at informatik.uni-halle.de> wrote:
> >
> >> Dear all,
> >> we are trying to set up an ImageJ update site for our plugin collection
> >> MiToBo. Since we have a lot of dependencies we would like to test the
> setup
> >> first on our own local server, but in the end we plan to provide Mitobo
> via
> >> an ImageJ Wiki update site. Unfortunately we encountered some problems.
> >> Amongst others we depend on two jars, sezpoz.jar and xalan.jar. Both
> jars
> >> seem to have been provided by the Fiji Update Site in former days, but
> are
> >> now declared obsolete. Since we need both of them we tried to upload
> them
> >> to our own site, however, this fails. First Fiji claims about changed
> >> checksums for both jar files. After recalculating the checksums and
> trying
> >> to upload them again, the updater throws the following exception:
> >>
> >> Upload failed: java.lang.NoClassDefFoundError:
> >> org/apache/xml/serializer/TreeWalker
> >>
> >> Then the updater can only be canceled and trying to re-run it requires
> >> recalculation of checksums again. Nevertheless the upload fails again
> with
> >> the above exception. Does anyone have an idea why it is not possible to
> >> upload both jars to our own site? For other jars unseen by Fiji before
> >> there were no problems.
> >>
> >> And finally two general questions:
> >>
> >> - What is Fiji's strategy to deal with cases where the same jar in
> >> different versions is provided by two update sites?
> >>
> >> - How does the updater try to determine depencies of plugins? In our
> case
> >> while checking our local jars it claimed to detect a cyclic dependency
> >> which was not there.
> >>
> >> Thanks and best regards,
> >>
> >>  Birgit
> >>
> >>
> >> ------------------------------------------------------------------------
> >> Dr. rer. nat. Birgit Moeller
> >>
> >> Pattern Recognition & Bioinformatics
> >> Institute of Computer Science / Faculty of Natural Sciences III
> >> Martin Luther University Halle-Wittenberg
> >>
> >> office:     Room 4.12
> >> phone:      +49(0)345-55-24745
> >> fax:        +49(0)345-55-27039
> >> snail mail: Von-Seckendorff-Platz 1, 06120 Halle / Saale (Germany)
> >> e-mail:     birgit.moeller at informatik.uni-halle.de
> >> www:        http://www.informatik.uni-halle.de/moeller/
> >> ------------------------------------------------------------------------
> >>
> >> --
> >> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
> >>
> >
> >--
> >ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>
> --
> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://imagej.net/pipermail/imagej-devel/attachments/20150320/25030f18/attachment-0001.html>