<div dir="ltr"><div><div><div><div><div>Hi Birgit,<br><br>>however, here I had to specify an explicit version. <br><br></div><div>This is because we don't explicitly manage the version of the bioformats_package component, since it's an uber-jar as you mentioned. In cases that you do need to specify a manual version, it would be best to use the ${bio-formats.version} property[1] to avoid mis-matched Bio-Formats versions.<br></div><div><br>>Is the package loci.formats.gui.* somewhere else available, or what is the best strategy to resolve these dependencies?<br><br></div>Yes, all the Bio-Formats code lives in individual components. I believe all of loci.formats.gui is in formats-bsd. Each component has its own Maven entry - you can see a list of them in pom-scijava[2], for example.<br><br></div>When I'm trying to remember which component a particular Bio-formats class is in, I often go to the master branch on GitHub[3], press 't' to start filtering, and type the class name. All of the Bio-Formats code is organized in /component/[component-name] file structure.<br><br></div>Fiji also ships a Find Jar for Class command[4], which is much more flexible than searching GitHub :)<br><br></div>Hope that helps.<br><br></div><div>Best,<br></div>Mark<br><div><div><div><div><div><div><br>[1] <a href="https://github.com/scijava/pom-scijava/blob/pom-scijava-6.1.0/pom.xml#L207">https://github.com/scijava/pom-scijava/blob/pom-scijava-6.1.0/pom.xml#L207</a><br>[2] <a href="https://github.com/scijava/pom-scijava/blob/pom-scijava-6.1.0/pom.xml#L443-503">https://github.com/scijava/pom-scijava/blob/pom-scijava-6.1.0/pom.xml#L443-503</a><br></div><div>[3] <a href="https://github.com/openmicroscopy/bioformats/tree/master">https://github.com/openmicroscopy/bioformats/tree/master</a><br>[4] <a href="http://fiji.sc/Tips_for_developers#find_the_.jar_file_containing_a_certain_class">http://fiji.sc/Tips_for_developers#find_the_.jar_file_containing_a_certain_class</a><br></div></div></div></div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Mar 28, 2015 at 1:42 PM, Birgit Moeller <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"><span class="">Hi Curtis!<br>
<br>
<br>
Curtis Rueden wrote<br>
> Hi Birgit,<br>
><br>
</span><div><div class="h5">> So your main deps are:<br>
><br>
>> loci:loci_tools:4.4.8<br>
>> net.imglib2:imglib2:2.2.0<br>
>> net.imglib2:imglib2-algorithms:2.0.0-beta-10<br>
><br>
> There are a couple of problems.<br>
><br>
> 1) The imglib2-algorithms artifact is obsolete. Since the 2.0.0 final<br>
> release of imglib2, the Algorithms library was renamed to<br>
> imglib2-algorithm<br>
> instead, for consistency.<br>
><br>
> 2) Bio-Formats 4.4.x is no longer shipped with Fiji. It currently ships<br>
> Bio-Formats 5.0.x, which will soon become 5.1.0 once the OME team<br>
> finalizes<br>
> that version. MiToBo will have compatibility problems with Fiji as long as<br>
> it still depends on 4.4.8.<br>
><br>
> I advise extending pom-imagej (or alternately, import it in your<br>
> dependencyManagement section [1]) to inherit its Bill of Materials [2], to<br>
> get consistency of versioning. Otherwise, you are just taking a stab in<br>
> the<br>
> dark at getting all the version numbers right. The BOM exists as a promise<br>
> to downstream projects that all the versions declared therein will work<br>
> together. In general, if you have not already read over the ImageJ<br>
> Architecture page [3], I would suggest doing so.<br>
><br>
> As of this writing, if you extend or import the newest pom-imagej 6.0.0,<br>
> you can then add the following dependencies:<br>
><br>
>> ome:formats-api (for loci.formats.*)<br>
>> ome:formats-common (for loci.common.*)<br>
>> ome:ome-xml (for ome.xml.*)<br>
>> ome:formats-bsd (runtime; for open file formats)<br>
>> ome:formats-gpl (runtime; for proprietary file formats)<br>
>> net.imglib2:imglib2<br>
>> net.imglib2:imglib2-algorithm<br>
><br>
> I did not bother to specify the version numbers above -- the whole point<br>
> is<br>
> that you would leave off the "<br>
> <version><br>
> ...<br>
> </version><br>
> " lines in your POM,<br>
> since they are managed by pom-imagej instead.<br>
><br>
> Happy to help if you need further information or assistance with this!<br>
<br>
</div></div>I changed our POM file as follows. In the dependency management section I<br>
added<br>
<br>
  <dependencyManagement><br>
    <dependencies><br>
      <dependency><br>
        <groupId>net.imagej</groupId><br>
        <artifactId>pom-imagej</artifactId><br>
        <version>6.0.0</version><br>
        <type>pom</type><br>
        <scope>import</scope><br>
      </dependency><br>
    </dependencies><br>
  </dependencyManagement><br>
<br>
and in the dependencies themselves I added all the artifacts you suggested.<br>
I did not add any version information and in general it seems to work. There<br>
was only one problem. We also use functionality from the loci.formats.gui.*<br>
package which is not covered by the dependencies you listed above. I found<br>
the packages that we need in<br>
<br>
<dependency><br>
   <groupId>ome</groupId><br>
   <artifactId>bioformats_package</artifactId><br>
   <version>5.0.4</version><br>
</dependency><br>
<br>
however, here I had to specify an explicit version. And if I understood you<br>
right, this is again an uber-jar probably not the best choice to depend on.<br>
Is the package loci.formats.gui.* somewhere else available, or what is the<br>
best strategy to resolve these dependencies?<br>
<br>
<br>
Curtis Rueden wrote<br>
<span class="">>> We currently don't have an SCM being publically accessible<br>
><br>
> If you are willing to change that, we would be delighted to add more<br>
> MiToBo<br>
> links in the relevant places of our SciJava propaganda. In particular:<br>
><br>
> * <a href="http://scijava.org/" target="_blank">http://scijava.org/</a><br>
> * <a href="http://imagej.net/Philosophy" target="_blank">http://imagej.net/Philosophy</a><br>
><br>
> And on the Architecture page too, adding (e.g.) a MiToBo GitHub<br>
> organization, pom-mitobo, etc., to the various tables.<br>
<br>
</span>Sounds great, we will discuss that option soon.<br>
<br>
<br>
Curtis Rueden wrote<br>
<span class="">> Currently we do include the MiToBo and Alida logos in our talks when we<br>
> mention SciJava module interoperability, but it would be nice to link to<br>
> more of your project resources.<br>
<br>
</span>Great, thanks! :-)<br>
<br>
<br>
Curtis Rueden wrote<br>
<span class="">> Regards,<br>
> Curtis<br>
><br>
> [1]<br>
> <a href="https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Importing_Dependencies" target="_blank">https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Importing_Dependencies</a><br>
> [2] <a href="http://imagej.net/BOM" target="_blank">http://imagej.net/BOM</a><br>
> [3] <a href="http://imagej.net/Architecture" target="_blank">http://imagej.net/Architecture</a><br>
><br>
</span>> [...]<br>
<br>
Kind regards,<br>
<br>
 Birgit<br>
<br>
<br>
<br>
<br>
--<br>
View this message in context: <a href="http://imagej-devel.54429.x6.nabble.com/Re-Problems-uploading-jars-to-update-site-tp940p954.html" target="_blank">http://imagej-devel.54429.x6.nabble.com/Re-Problems-uploading-jars-to-update-site-tp940p954.html</a><br>
<div class="HOEnZb"><div class="h5">Sent from the ImageJ-devel mailing list archive at Nabble.com.<br>
<br>
_______________________________________________<br>
ImageJ-devel mailing list<br>
<a href="mailto:ImageJ-devel@imagej.net">ImageJ-devel@imagej.net</a><br>
<a href="http://imagej.net/mailman/listinfo/imagej-devel" target="_blank">http://imagej.net/mailman/listinfo/imagej-devel</a><br>
</div></div></blockquote></div><br></div>