Re: AW: How to handle dependencies

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: AW: How to handle dependencies

dscho
Hi Heinrich,

On Tue, 21 Jan 2014, Heinrich Grabmayr wrote:

> Finally, I have now set up a maven project in netbeans for my plugins
> pacakge (including several classes). This is so amazingly great!!

Glad it worked out for you!

> I set the dependencies to the old versions I know my code compiles with.
> Now I would like to update the dependencies. Is there a way to do that
> gradually, e.g. for one class at a time or so? This might make it easier
> to debug?

Unfortunately, you cannot update the dependencies on a class-by-class
basis. All you can do is to upgrade the dependencies one by one to newer
versions.

On the assumption that the problem is ImageJ 1.x, here are the steps to
define the ImageJ dependency to a new version:

- edit pom.xml and locate the <dependencies> section

- you will find something like

                <dependency>
                        <groupId>net.imagej</groupId>
                        <artifactId>ij</artifactId>
                        <version>${imagej1.version}</version>
                </dependency>

- there are two ways to switch the version:

        1) replace "${imagej1.version}" by something like "1.48o", or

        2) define a property in the <properties> section instead:

                <properties>
                        <imagej1.version>1.48i</imagej1.version>
                </properties>

  in both cases, you override the property set by the parent project
  defined in the <parent> section at the beginning of the pom.xml file.

- after saving the edited pom.xml, you will most likely have to tell
  Netbeans that the project changed and that it needs to refresh the
  project settings.

Ciao,
Johannes

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html
Reply | Threaded
Open this post in threaded view
|

Re: AW: AW: How to handle dependencies

dscho
Dear Heinrich,

On Thu, 23 Jan 2014, Heinrich Grabmayr wrote:

> Last May when you announced the personal update sites on
> sites.imagej.net, I set one up. Now I was thinking whether it makes
> sense to have the pom.xml upload the resulting jar there, directly. What
> do you think/what is the best way to handle this?

That is actually not possible. The reason is that we're talking about two
very different things: on the one hand, the Maven project for developers
which can be opened, modified, run and be debugged in an integrated
development environment and which should only run your plugin. On the
other hand, we are talking about update sites for users, for which you
have to set up such a user installation yourself to be sure that your
plugin works as expected even with other plugins being present in the
plugins/ directory.

The best way to help connect the both I could come up so far is the
imagej-maven-plugin which is configured automatically if you use
pom-scijava as your parent project.

The idea is that you can set the property imagej.app.directory to point to
your ImageJ/Fiji/ImageJ2 installation and the plugin will automatically
install your plugin (and all of its dependencies) into said directory.

Example: let's assume that you have unpacked a regular Fiji package onto
your Desktop/ and you have your plugin project sitting in
workspace/Heinrichs_Plugin/. Then calling

        cd $HOME/workspace/Heinrichs_Plugin/
        mvn -Dimagej.app.directory=$HOME/Desktop/Fiji.app

(appropriately quoted if your home directory's path contains spaces) will
copy your plugin to Desktop/Fiji.app/plugins/ and after testing it, you
can use the updater to upload your plugin to your update site as described
here:

        http://fiji.sc/How_to_set_up_and_populate_an_update_site

If you have ideas how to improve this or make it easier, please do let me
know!

Ciao,
Johannes

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html
Reply | Threaded
Open this post in threaded view
|

Re: AW: AW: AW: How to handle dependencies

dscho
Hi Heinrich,

On Mon, 27 Jan 2014, Grabmayr, Heinrich wrote:

> Maven now copies the plugin jar and the needed dpendencies into the copy
> of Fiji I usually work with. When I now start Fiji, it tells me that
> there are multiple conflicting dependencies and when I update Fiji,
> there are CriticalErrors, also about multiple jars.
> e.g.
> CriticalError: plugins/loci_plugins-4.4.10.jar
> Multiple locally-modified versions of plugins/loci_plugins-4.4.10.jar exist: C:\Users\ne85tib\Desktop\Fiji.app\plugins\loci_plugins-4.4-SNAPSHOT.jar
>
> Do I understand correctly that I need to use exactly the same versions
> in maven as are used in the current Fiji plugin distribution? I tried to
> use version 4.4.10 of loci_plugins but Maven did not find that somehow.

The problem is that there are multiple versions of the same dependencies.
If all of those dependencies are developed according to SemVer
(http://semver.org) it is often possible to simply use the newest version
(SemVer suggests to indicate via the version number whether it is safe to
do so: bug fixes increase the micro version, backwards-compatible
enhancements increase the minor version, backwards *incompatible* changes
increase the major version).

Sadly, SemVer is not used for all of the components in the Fiji universe,
most notably for ImgLib2 and ImageJ 1.x itself.

Having said that, Bio-Formats seems to be developed according to SemVer,
so it should be totally safe to tell the imagej-maven-plugin to delete
other versions when copying a dependency: You only need to set the
property "delete.other.versions" to "true". Example:

        mvn -Dimagej.app.directory=$HOME/Desktop/Fiji.app \
                -Ddelete.other.versions=true

Ciao,
Johannes

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html
Reply | Threaded
Open this post in threaded view
|

AW: AW: AW: AW: How to handle dependencies

Heerpa
 Hi Johannes
 >
 > > Maven now copies the plugin jar and the needed dpendencies into the
 > > copy of Fiji I usually work with. When I now start Fiji, it tells me
 > > that there are multiple conflicting dependencies and when I update
 > > Fiji, there are CriticalErrors, also about multiple jars.
 > > e.g.
 > > CriticalError: plugins/loci_plugins-4.4.10.jar Multiple
 > > locally-modified versions of plugins/loci_plugins-4.4.10.jar exist:
 > > C:\Users\ne85tib\Desktop\Fiji.app\plugins\loci_plugins-4.4-SNAPSHOT.
 > > ja
 > > r
 > >
 > > Do I understand correctly that I need to use exactly the same
 > > versions in maven as are used in the current Fiji plugin
 > > distribution? I tried to use version 4.4.10 of loci_plugins but Maven
did
 not find that somehow.
 >
 > The problem is that there are multiple versions of the same dependencies.
 > If all of those dependencies are developed according to SemVer
 > (http://semver.org) it is often possible to simply use the newest
 > version (SemVer suggests to indicate via the version number whether it
 > is safe to do
 > so: bug fixes increase the micro version, backwards-compatible
 > enhancements increase the minor version, backwards *incompatible*
 > changes increase the major version).
 >
 > Sadly, SemVer is not used for all of the components in the Fiji
 > universe, most notably for ImgLib2 and ImageJ 1.x itself.
 >
 > Having said that, Bio-Formats seems to be developed according to
 > SemVer, so it should be totally safe to tell the imagej-maven-plugin
 > to delete other versions when copying a dependency: You only need to
 > set the property "delete.other.versions" to "true". Example:
 >
 > mvn -Dimagej.app.directory=$HOME/Desktop/Fiji.app \
 > -Ddelete.other.versions=true
 
 I am using NetBeans, and just select "Clean and Build" when I want to
 compile the code / execute the pom. Therefore I guess command line is not
 suitable. Thus, I included the property
 
         <properties>
 
 <imagej.app.directory>C:\Users\ne85tib\Desktop\Fiji.app</imagej.app.dire
 ctory> <!-- Path to fiji here for testing the plugins and uploading to the
server
 -->
             <delete.other.versions>true</delete.other.versions> <!-- found
on
 http://imagej.1557.x6.nabble.com/Eclipse-Maven-workflow-depencies-
 copied-to-Fiji-app-directory-td5005804.html -->
         </properties>
 
 into my pom.xml (which is taken from  the minimal ij plugin-github
 repository), its parent is
 
  <parent>
  <groupId>org.scijava</groupId>
  <artifactId>pom-scijava</artifactId>
  <version>1.51</version>
  </parent>
 
 However, the other versions are not deleted - the same problem remains.
 NetBeans output tells me about which dependencies it copies during the
 copy-jars task but there is nothing on checking or deleting other versions.
Do
 you have any more suggestions?
 
 Best,
    Heinrich

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html
Reply | Threaded
Open this post in threaded view
|

Re: AW: AW: AW: How to handle dependencies

Heerpa
In reply to this post by dscho
Hi List,

Just in case somebody has the same issue at some point in the future:
Previously, I had the problem of dependencies not getting deleted even when
I set the property
            <delete.other.versions>true</delete.other.versions>
I now noticed that I had used the pom-scijava 1.51 as a parent and had
thought this was the current version. Using version 1.129, the other
versions of dependencies are deleted very nicely in the set IJ folder.

        <parent>
                <groupId>org.scijava</groupId>
                <artifactId>pom-scijava</artifactId>
                <version>1.129</version>
                <relativePath />
        </parent>

For this change to work, I also had to change
<!-- <repository>
                        <id>imagej.releases</id>
       
<url>http://maven.imagej.net/content/repositories/releases</url>
                </repository>-->

To
                <repository>
                        <id>imagej.public</id>
       
<url>http://maven.imagej.net/content/groups/public</url>
                </repository>

Otherwise, maven would not find the dependencies any more.
Ciao, Heinrich

-----Original Message-----
From: Grabmayr, Heinrich
Sent: Montag, 27. Januar 2014 16:19
To: Johannes Schindelin
Cc: 'Heinrich Grabmayr'; 'ImageJ Interest Group'
Subject: AW: AW: AW: AW: How to handle dependencies

Hi Johannes

>
> > Maven now copies the plugin jar and the needed dpendencies into the
> > copy of Fiji I usually work with. When I now start Fiji, it tells me
> > that there are multiple conflicting dependencies and when I update
> > Fiji, there are CriticalErrors, also about multiple jars.
> > e.g.
> > CriticalError: plugins/loci_plugins-4.4.10.jar Multiple
> > locally-modified versions of plugins/loci_plugins-4.4.10.jar exist:
> > C:\Users\ne85tib\Desktop\Fiji.app\plugins\loci_plugins-4.4-SNAPSHOT.
> > ja
> > r
> >
> > Do I understand correctly that I need to use exactly the same
> > versions in maven as are used in the current Fiji plugin
> > distribution? I tried to use version 4.4.10 of loci_plugins but Maven
did not find that somehow.

>
> The problem is that there are multiple versions of the same dependencies.
> If all of those dependencies are developed according to SemVer
> (http://semver.org) it is often possible to simply use the newest
> version (SemVer suggests to indicate via the version number whether it
> is safe to do
> so: bug fixes increase the micro version, backwards-compatible
> enhancements increase the minor version, backwards *incompatible*
> changes increase the major version).
>
> Sadly, SemVer is not used for all of the components in the Fiji
> universe, most notably for ImgLib2 and ImageJ 1.x itself.
>
> Having said that, Bio-Formats seems to be developed according to
> SemVer, so it should be totally safe to tell the imagej-maven-plugin
> to delete other versions when copying a dependency: You only need to
> set the property "delete.other.versions" to "true". Example:
>
> mvn -Dimagej.app.directory=$HOME/Desktop/Fiji.app \
> -Ddelete.other.versions=true

I am using NetBeans, and just select "Clean and Build" when I want to
compile the code / execute the pom. Therefore I guess command line is not
suitable. Thus, I included the property

        <properties>
 
<imagej.app.directory>C:\Users\ne85tib\Desktop\Fiji.app</imagej.app.director
y> <!-- Path to fiji here for testing the plugins and uploading to the
server -->
            <delete.other.versions>true</delete.other.versions> <!-- found
on
http://imagej.1557.x6.nabble.com/Eclipse-Maven-workflow-depencies-copied-to-
Fiji-app-directory-td5005804.html -->
        </properties>

into my pom.xml (which is taken from  the minimal ij plugin-github
repository), its parent is

        <parent>
                <groupId>org.scijava</groupId>
                <artifactId>pom-scijava</artifactId>
                <version>1.51</version>
        </parent>

However, the other versions are not deleted - the same problem remains.
NetBeans output tells me about which dependencies it copies during the
copy-jars task but there is nothing on checking or deleting other versions.
Do you have any more suggestions?

Best,
   Heinrich

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html
Reply | Threaded
Open this post in threaded view
|

Re: AW: AW: AW: How to handle dependencies

dscho
Hi Heinrich,

On Wed, 12 Feb 2014, Heinrich Grabmayr wrote:

> Just in case somebody has the same issue at some point in the future:
> Previously, I had the problem of dependencies not getting deleted even when
> I set the property
>             <delete.other.versions>true</delete.other.versions>
> I now noticed that I had used the pom-scijava 1.51 as a parent and had
> thought this was the current version. Using version 1.129, the other
> versions of dependencies are deleted very nicely in the set IJ folder.

I am glad you found the solution!

Ciao,
Johannes

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html