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