Hi Birgit,
>however, here I had to specify an explicit version.
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.
>Is the package loci.formats.gui.* somewhere else available, or what is the
best strategy to resolve these dependencies?
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.
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.
Fiji also ships a Find Jar for Class command[4], which is much more
flexible than searching GitHub :)
Hope that helps.
Best,
Mark
[1]
https://github.com/scijava/pom-scijava/blob/pom-scijava-6.1.0/pom.xml#L207
[2]
https://github.com/scijava/pom-scijava/blob/pom-scijava-6.1.0/pom.xml#L443-503
[3] https://github.com/openmicroscopy/bioformats/tree/master
[4]
http://fiji.sc/Tips_for_developers#find_the_.jar_file_containing_a_certain_class
On Sat, Mar 28, 2015 at 1:42 PM, Birgit Moeller <
birgit.moel...@informatik.uni-halle.de> wrote:
> 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
> added
>
> <dependencyManagement>
> <dependencies>
> <dependency>
> <groupId>net.imagej</groupId>
> <artifactId>pom-imagej</artifactId>
> <version>6.0.0</version>
> <type>pom</type>
> <scope>import</scope>
> </dependency>
> </dependencies>
> </dependencyManagement>
>
> 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
>
> <dependency>
> <groupId>ome</groupId>
> <artifactId>bioformats_package</artifactId>
> <version>5.0.4</version>
> </dependency>
>
> 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,
>
> Birgit
>
>
>
>
> --
> 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.
>
> _______________________________________________
> ImageJ-devel mailing list
> ImageJ-devel@imagej.net
> http://imagej.net/mailman/listinfo/imagej-devel
>
_______________________________________________
ImageJ-devel mailing list
ImageJ-devel@imagej.net
http://imagej.net/mailman/listinfo/imagej-devel
