[ImageJ-devel] Problems uploading jars to update site

Birgit Moeller birgit.moeller at informatik.uni-halle.de
Sat Mar 28 13:42:06 CDT 2015

Hi Curtis!

Curtis Rueden wrote
> Hi Birgit,
> So your main deps are:
>> loci:loci_tools:4.4.8
>> net.imglib2:imglib2:2.2.0
>> net.imglib2:imglib2-algorithms:2.0.0-beta-10
> There are a couple of problems.
> 1) The imglib2-algorithms artifact is obsolete. Since the 2.0.0 final
> release of imglib2, the Algorithms library was renamed to
> imglib2-algorithm
> instead, for consistency.
> 2) Bio-Formats 4.4.x is no longer shipped with Fiji. It currently ships
> Bio-Formats 5.0.x, which will soon become 5.1.0 once the OME team
> finalizes
> that version. MiToBo will have compatibility problems with Fiji as long as
> it still depends on 4.4.8.
> I advise extending pom-imagej (or alternately, import it in your
> dependencyManagement section [1]) to inherit its Bill of Materials [2], to
> get consistency of versioning. Otherwise, you are just taking a stab in
> the
> dark at getting all the version numbers right. The BOM exists as a promise
> to downstream projects that all the versions declared therein will work
> together. In general, if you have not already read over the ImageJ
> Architecture page [3], I would suggest doing so.
> As of this writing, if you extend or import the newest pom-imagej 6.0.0,
> you can then add the following dependencies:
>> ome:formats-api (for loci.formats.*)
>> ome:formats-common (for loci.common.*)
>> ome:ome-xml (for ome.xml.*)
>> ome:formats-bsd (runtime; for open file formats)
>> ome:formats-gpl (runtime; for proprietary file formats)
>> net.imglib2:imglib2
>> net.imglib2:imglib2-algorithm
> I did not bother to specify the version numbers above -- the whole point
> is
> that you would leave off the "
> <version>
> ...
> </version>
> " lines in your POM,
> since they are managed by pom-imagej instead.
> Happy to help if you need further information or assistance with this!

I changed our POM file as follows. In the dependency management section I


and in the dependencies themselves I added all the artifacts you suggested.
I did not add any version information and in general it seems to work. There
was only one problem. We also use functionality from the loci.formats.gui.*
package which is not covered by the dependencies you listed above. I found
the packages that we need in 


however, here I had to specify an explicit version. And if I understood you
right, this is again an uber-jar probably not the best choice to depend on.
Is the package loci.formats.gui.* somewhere else available, or what is the
best strategy to resolve these dependencies?

Curtis Rueden wrote
>> We currently don't have an SCM being publically accessible
> If you are willing to change that, we would be delighted to add more
> MiToBo
> links in the relevant places of our SciJava propaganda. In particular:
> * http://scijava.org/
> * http://imagej.net/Philosophy
> And on the Architecture page too, adding (e.g.) a MiToBo GitHub
> organization, pom-mitobo, etc., to the various tables.

Sounds great, we will discuss that option soon.

Curtis Rueden wrote
> Currently we do include the MiToBo and Alida logos in our talks when we
> mention SciJava module interoperability, but it would be nice to link to
> more of your project resources.

Great, thanks! :-)

Curtis Rueden wrote
> Regards,
> Curtis
> [1]
> https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Importing_Dependencies
> [2] http://imagej.net/BOM
> [3] http://imagej.net/Architecture
> [...]

Kind regards,


View this message in context: http://imagej-devel.54429.x6.nabble.com/Re-Problems-uploading-jars-to-update-site-tp940p954.html
Sent from the ImageJ-devel mailing list archive at Nabble.com.

More information about the ImageJ-devel mailing list