imagej/imagej-maven-plugin

[OBSOLETE] All goals migrated to scijava/scijava-maven-plugin

ImageJ

ImageJ is public domain software for processing and analyzing scientific images.

It is written in Java, which allows it to run on many different platforms.

For further information, see:

• The ImageJ website, the primary home of this project.
• The ImageJ wiki, a community-built knowledge base covering ImageJ and its derivatives and flavors, including ImageJ2, Fiji, and others.
• The ImageJ mailing list and Image.sc Forum for community support.
• The Contributing page of the ImageJ wiki for details on how to contribute.

Using ImageJ as a dependency

To use ImageJ as a library in your Maven project, add the dependency:

<dependency>
  <groupId>net.imagej</groupId>
  <artifactId>ij</artifactId>
  <version>1.53j</version>
</dependency>

Where 1.53j is the version of ImageJ you would like to use:

• Versions up to 1.48q are in the SciJava Maven repository.
• Versions starting with 1.48r are on Maven Central.
• Be aware that versions prior to 1.53k may not identically match the corresponding release tags here in this repository.

Building from source

With Ant

The Apache Ant utility will compile and run ImageJ using the build.xml file in this directory. There is a version of Ant at

https://imagej.nih.gov/ij/download/tools/ant/ant.zip

set up to use the JVM distributed with the Windows version of ImageJ. The README included in the ZIP archive has more information.

With Maven

You can compile and run ImageJ using the Maven build tool:

Command	Action
mvn	Compile and package ImageJ into a JAR file in the target directory.
mvn -Pexec	Compile and then run ImageJ.
mvn javadoc:javadoc	Generate the project Javadoc in the target/apidocs directory.

imagej-maven-plugin's Issues

mvn -Dimagej.app.directory=… for plugins requires _ in name

mvn -Dimagej.app.directory=/home/me/Fiji.app install

for plugins that have a

<name>plugins/myPlugin.jar</name>

does not copy the target into

/home/me/Fiji.app/plugins

but into

/home/me/Fiji.app/jars

whereas

<name>plugins/my_Plugin.jar</name>

would be copied into

/home/me/Fiji.app/plugins

If I understood @rasband correctly, _ is not required any more to recognize plugins. If that is true, it should not be required by the copy rule either.

Test-scoped dependencies must not be copied

junit is copied, and scijava-common-tests is preferred over scijava-common...

Ignore excluded dependencies

We have not used any <exclusions> blocks in our dependency declarations... until today. Now that we have need to exclude some transitive dependencies in this way (specifically: the gov.nih.imagej:imagej artifact from the ome:bio-formats_plugins dependency), it would be nice if imagej-maven-plugin respected such exclusions and did not copy excluded transitive dependencies into the jars or plugins folders.

Java3D .jar files get copied to jars/

Either MiniMaven or the imagej-maven-plugin copy the Java3D .jar files into jars/. They should not do that.

Migrated-From: http://trac.imagej.net/ticket/1848

Improve log messages for incompatible versions

Currently, the log message does not contain the name of the artifact for which an incompatible version exists.

[WARNING] Found other version that is incompatible according to SemVer.

Make imagej.app.directory outisde of pom.xml ?

I would like to not track imagej.app.directory property by git by putting it outside the pom.xml file. I am using Netbeans for development and so a method compatible with it would be nice :-)

Any idea ?

Expand copy-jars to also copy non-JAR resources

A Maven project such as imagej/imagej or fiji/fiji should be able to put scripts and other non-JAR resources somewhere (maybe src/main/imagej by default), such that they will get copied by the imagej-maven-plugin into an ImageJ installation when one is provided via the imagej.app.directory property.

Teach the imagej-maven-plugin to copy locally-installed versions if they are newer

At the moment, the imagej-maven-plugin always copies dependencies from the remote. But it should use the locally installed ones instead so that one can try out changes spanning multiple projects.

Migrated-From: http://trac.imagej.net/ticket/1732

Multi-module projects do not work(?)

Try building BoneJ2 with an imagej.app.directory set and pom-scijava >= 21.0.0. (Specifically: imagej-maven-plugin 0.7.0 rather than 0.6.0.) The build fails with the following error:

[ERROR] Failed to execute goal net.imagej:imagej-maven-plugin:0.7.0:copy-jars (copy-jars) on project pom-bonej2: Couldn't resolve dependencies for artifact: org.eclipse.aether.resolution.DependencyResolutionException: Could not find artifact org.bonej:pom-bonej2:jar:0.4.0-SNAPSHOT in imagej.public (http://maven.imagej.net/content/groups/public) -> [Help 1]

Running mvn -DskipTests clean install first does not alleviate the issue.

See also this conversation on Gitter.

Improve handling of incompatible versions

Would it make sense to at least log a warning when overriding an older version of an artifact that is incompatible (according to SemVer) with a newer one? Should this be an extra property?

Does anyone have an opinion on this, @imagejan, @ctrueden?

NPE when copying dependencies for fiji/fiji

One the current fiji/fiji master branch (fiji/fiji@969b2d4), running mvn -X -Dimagej.app.directory=Fiji.app fails to copy the dependencies, producing the following failure:

[ERROR] Failed to execute goal net.imagej:imagej-maven-plugin:0.7.0:copy-jars (copy-jars) on project fiji: Execution copy-jars of goal net.imagej:imagej-maven-plugin:0.7.0:copy-jars failed.: NullPointerException -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal net.imagej:imagej-maven-plugin:0.7.0:copy-jars (copy-jars) on project fiji: Execution copy-jars of goal net.imagej:imagej-maven-plugin:0.7.0:copy-jars failed.
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:213)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:154)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:146)
    at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:117)
    at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:81)
    at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build (SingleThreadedBuilder.java:51)
    at org.apache.maven.lifecycle.internal.LifecycleStarter.execute (LifecycleStarter.java:128)
    at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:309)
    at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:194)
    at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:107)
    at org.apache.maven.cli.MavenCli.execute (MavenCli.java:955)
    at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:290)
    at org.apache.maven.cli.MavenCli.main (MavenCli.java:194)
    at sun.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:62)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke (Method.java:498)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced (Launcher.java:289)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launch (Launcher.java:229)
    at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode (Launcher.java:415)
    at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:356)
Caused by: org.apache.maven.plugin.PluginExecutionException: Execution copy-jars of goal net.imagej:imagej-maven-plugin:0.7.0:copy-jars failed.
    at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo (DefaultBuildPluginManager.java:145)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:208)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:154)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:146)
    at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:117)
    at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:81)
    at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build (SingleThreadedBuilder.java:51)
    at org.apache.maven.lifecycle.internal.LifecycleStarter.execute (LifecycleStarter.java:128)
    at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:309)
    at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:194)
    at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:107)
    at org.apache.maven.cli.MavenCli.execute (MavenCli.java:955)
    at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:290)
    at org.apache.maven.cli.MavenCli.main (MavenCli.java:194)
    at sun.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:62)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke (Method.java:498)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced (Launcher.java:289)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launch (Launcher.java:229)
    at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode (Launcher.java:415)
    at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:356)
Caused by: java.lang.NullPointerException
    at net.imagej.maven.AbstractCopyJarsMojo.installArtifact (AbstractCopyJarsMojo.java:183)
    at net.imagej.maven.AbstractCopyJarsMojo.installArtifact (AbstractCopyJarsMojo.java:139)
    at net.imagej.maven.CopyJarsMojo.execute (CopyJarsMojo.java:188)
    at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo (DefaultBuildPluginManager.java:134)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:208)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:154)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:146)
    at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:117)
    at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:81)
    at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build (SingleThreadedBuilder.java:51)
    at org.apache.maven.lifecycle.internal.LifecycleStarter.execute (LifecycleStarter.java:128)
    at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:309)
    at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:194)
    at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:107)
    at org.apache.maven.cli.MavenCli.execute (MavenCli.java:955)
    at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:290)
    at org.apache.maven.cli.MavenCli.main (MavenCli.java:194)
    at sun.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:62)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke (Method.java:498)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced (Launcher.java:289)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launch (Launcher.java:229)
    at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode (Launcher.java:415)
    at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:356)

Using imagej-maven-plugin 0.6.0 does not have this problem, but then does not benefit from the improved dependency handling.

Improve detection of other versions

Currently, there is a filename/regex-based check for determining if a file in imagej.app.directory conflicts with the artifact to be installed. While this check works, it has hardcoded patterns and is thus not extensible if e.g. artifacts with new architectures show up.

We (@ctrueden and I) have come up with the following scheme to extract the version and qualifier from a Jar file:

1. Look in Jar for version information:
   1. pom.xml in META-INF (if found, return)
   2. MANIFEST.mf (implementation version)
2. If the version is found in the filename suffix, the rest is a qualifier [If not: ij.jar or inconsistent: warning]
3. If nothing is in the filename
   1. use regex (dash+digit: substring)
   2. if there is no version, assume there is a qualifier or suffix

Add -Ddelete.older.versions flag

Probably named -Dimagej.deleteOlderVersions actually, but we need functionality like delete.other.versions but only when the existing libraries are older according to SemVer.

Set "-Ddelete.other.versions=true" as default

The "delete other versions" option of the copy-jars mojo is almost always what people want. It should be the default.

Add goal for uploading to an ImageJ update site

Right now, to automate uploads to update sites, the easiest way is to bootstrap an ImageJ2 installation—typically by downloading a platform-specific Fiji bundle and unpacking it—and then copy stuff into the installation and use the command line ImageJ updater to upload everything. Unfortunately, there have been reports (e.g., this one from @tferr) of difficulties with this approach.

Much better would be if it could be done directly from your Maven component: mvn imagej:upload.

Thanks to @hadim for the idea.

Add a goal to install artifacts and their dependencies without needing a current project

We could make good use of such a goal in, say, the TrackMate-dev update site.

Make copy-jars/install-artifact semver-compatible

No need to delete a newer version -- if compatible!

Add flag to disable copying of dependencies

Currently, copy-jars as well as install-artifact handle the artifact and its dependencies in the same way. Sometimes it would be useful to just install the artifact itself and ignore dependencies (suggested by @ctrueden).

Use POM.compareTo() instead of VersionUtils.compare()

Use POM.compareTo() (introduded in scijava/scijava-common@c02cca4) instead of VersionUtils.compare() when checking for newer/older versions of an artifact in AbstractCopyJarsMojo.java#L184.

Migrate to Maven 3 APIs

maven-3-api-clean-up

Deploy to OSS Sonatype

Migrate generic functionality to scijava-maven-plugin

• Update https://github.com/scijava/pom-scijava-base/blob/3f39e0165b688df115ca3d441e3682619f547b3f/pom.xml#L775-L791 to reflect migration
• Continue support for imagej.app.directory
• Continue support for imagej.app.subdirectory
• Continue support for imagej.deleteOtherVersions
• Continue support for delete.other.versions?
• Update README to state that copy-jars has been migrated to scijava-maven-plugin
• Mark copy-jars and install-artifact as deprecated

Teach copy-jars about `nar` artifacts

When encountering a nar artifact, we should not just ignore it, but rather download it, then look for all platforms known to ImageJ (win32, win64, linux32, linux64 and macosx) and copy the respective attached artifacts -- insofar present -- into the lib/<platform>/ subdirectory.