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 |
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 |
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 |
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 |
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 > > 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 |
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 |
Free forum by Nabble | Edit this page |