Help with mvn in fiji

Hi all,

Having merged the numeric-pow branch into imglib2, now I’d like imglib2-algorithm to be able to use the newly added Pow functionality in RealType.

Unfortunately, my usual shortcut:

mvn -Dmaven.test.skip=true clean install

… can’t compile imglib2-algorithm.

What mvn incancation will solve this issue?

Thank you,


1 Like

Hey @albertcardona,

what’s the error message?


1 Like

The error is that the pow method of subclasses of RealType isn’t showing. The pom.xml of imglib2-algorithm likely needs updating to catch the latest imglib2 jar, or something–mvn is a like ministry of silly walks inside a black box.

1 Like

I assume you mvn install imglib2-algorithm locally and you are linking in your pom to the right imglib2 and imglib2-algorithm versions?

Feel free to point us to code :wink:

1 Like

imglib2 changed after merging the numeric-pow branch, and now there’s RealType.pow. I’ve compiled imglib2 into the

Then I’ve attempted to use the RealType.pow method from imglib2-algorithm in its math subpackage, but RealType.pow can’t be found at compile time.

Both with mvn into as above.

To attempt to solve the issue, I also run “mvn install” inside imglib2. That didn’t have any effect towards

mvn -Dmaven.test.skip=true clean install

… in the imglib2-algorithm directory: same compile error about lack of RealType.pow.

I mean quantum electrodynamics is easier to understand than maven. Who will be the Feynman of maven and make it make sense for the rest of us mere mortals?

With maven, I’ve installed the new imglib2. The pom.xml for imglib2-algorithm doesn’t specify any particular version of imglib2:

    <!-- ImgLib2 dependencies -->

What else does maven need to compile imglib2-algorithm when no other dependency has changed and the one that has, has been installed, both system-wide and at the target directory?

Perhaps the issue became a bit clearer now: there isn’t an imglib2-5.10-SNAPSHOT.jar under The command above FAILS to copy the jar there, despite having worked fine for years. So the flag perhaps is ignored now, for some reason, in Apache Maven 3.6.3. Manually copying the jar now …

1 Like

Sometimes, in situations like this, I compile/install the library of interest myself with version 1.2.3-robert locally and specify it in the other project explicitly. It may take time until the new versions are propagated as imglib2 and imglib2-algorithm have to be deployed together with the respective parent-pom which actually states the current version of all the jars.

tldr: Can you try explicitly specifying the version of imglib2 you want to use?

The point of maven is that one shouldn’t have to do things manually.


I know, but as long as the version is not planet wide distributed, you may need to go like this.

This post was flagged by the community and is temporarily hidden.


:slight_smile: Btw I solved that issue for myself at some point by introducing an own parent-pom for my projects. So I can define versions globally on my little planet :earth_africa:

So much maven grief just for this, to compile imglib2-algorithm:

$ javac -d my-build -classpath imglib2-5.10.0-SNAPSHOT.jar:imglib2-roi-0.10.4-SNAPSHOT.jar:imglib2-realtransform-2.2.1.jar:jama-1.0.3.jar:trove4j-3.0.3.jar:ojalgo-45.1.1.jar `find -name "*java" -printf "%p "` 2>&1 | less

Then I opened the imglib-algorithm jar and replaced its “net” folder with the one under “my-build”. Done!

1 Like

Sorry to see you suffer here on a Saturday evening.

Maven has simplified my life with Java soooo much, maybe I can share at least the bit I understood about it… even if I understand you have found a solution that works for you.

I think you might be conflating two concepts here:

  • What maven calls install is the storage of a compiled jar file (at a specific version) in your ~/.m2/ folder, the “Maven repository”.
  • What you call “compile into” is a separate “goal”, copy-jars – defined by the scijava-maven-plugin – that copies the jar file into a given Fiji installation (or more general: any SciJava application), in addition to the installation into the maven repository that happened earlier during the build.

Just because you copied the SNAPSHOT version into your Fiji installation, it doesn’t mean that when you compile imglib2-algorithm, it will know about that new version, because it will use the versions defined in its own pom.xml (either explicitly, or inherited by pom-scijava, see explanation below).

Please mind your words. You’re free to compile with javac and it will work with Fiji, nobody forces you to work with Maven. Nevertheless, I have to say that it simplified the development workflows of a lot of people I know (including myself), who would probably be struggling with dependency issues and version skews even more than with Maven.

That’s because it uses the version managed by the pom-scijava parent. That usually makes it easier because you don’t have to think about which version it is that everybody else in the Fiji universe is currently using.
Nonetheless, you can always override the managed (inherited) version property:


If you depend on SNAPSHOT versions (which you have to, because there’s no release version yet containing RealType.pow), you will have to skip the maven-enforcer-plugin temporarily by running Maven like this:

mvn clean install -Denforcer.skip

Instead of editing the pom.xml of imglib2-algorithm, you can also define the version property directly when building from the command line:

mvn clean install -Denforcer.skip -Dimglib2.version=5.10.0-SNAPSHOT

I sincerely hope this will help anyone who stumbles upon this forum topic in the future :slightly_smiling_face:


Thanks Jan. I do know more about maven than I care to admit.

What I had run:

$ cd imglib2/
$ mvn install
$ mvn -Dmaven.test.skip=true clean install

$ cd ../imglib2-algorithm/
$ mvn -Dmaven.test.skip=true clean install

But this was, somehow, not enough.

Will keep in mind the -Denforcer.skip flag for next time.

On the “nobody forces you to work with Maven”, well: Fiji’s original build system did a better job by a mile at handling the simple everyday cases. Maven is good at the massively distributed and compartmentalized framework that Fiji is today. What I find sorely missing is the everyday case for the lone developer who isn’t a trained developer but a biologist with a narrow goal in mind, i.e. writing a specific piece of code for a specific use case. For the latter, scripting rules nowadays–I made sure that was the case. But in the rare occasions that I am doing infrastructure work, I find the toolkit unfriendly, unforgiving, and dreadful.

1 Like

Ah, and I forgot: last I tried, java compilation from the Script Editor was broken. And class lookup too. That broke long, long ago, with the promise of a replacement that never came. Another stick on the wheels of the entry-level developer.

1 Like

Yes. As I tried to explain above, this builds the SNAPSHOT version of imglib2 and installs it both into your Maven (~/.m2/) repository and in your ~/ But when building imglib2-algorithm, there’s no way for Maven to know that you want to use that latest version: if you don’t specify it, it will use the version managed by its (parent) POM.

The last line of your call should have been:

$ cd ../imglib2-algorithm/
$ mvn -Dmaven.test.skip=true -Dimglib2.version=5.10.0-SNAPSHOT clean install

By the way: (while still being supported for backwards compatibility) can be replaced by


Thanks. While this is the solution, it clearly illustrates the problem with maven: the default is not to use the SNAPSHOT, which to me is what makes sense. It is the exception to want to specify an older, non-SNAPSHOT version, requiring specifying the numbered version in the mvn invocation command. But no, maven does the opposite.

Can maven be configured to always use the jar SNAPSHOT if available? I’d like to turn on that flag.

Maven is our guarantee for reproducible builds. It would be fatal if it would just pick up a SNAPSHOT version available on your local system without you explicitly telling it to do so: the same code would not build the same way on two different systems.

I think you can use the developer profiles defined in pom-scijava:

As written in that comment, it should be as easy as adding an empty dev.imglib2 file to your ~/.scijava/ directory.
Alternatively, according to the documentation, you should be able to run:

mvn -P dev.imglib2

I’ve never used those profiles though (as I’m rarely working on multi-module builds but rather on single components). @ctrueden will certainly be able to advise further.

Let us know how that works for you.


The LATEST keyword is a nice shortcut: it signifies the newest available SNAPSHOT version. Similarly, the RELEASE keyword signifies the newest available release (i.e. non-SNAPSHOT) version.

Here’s one way to build imglib2, and then imglib2-algorithm depending on it:

$ cd ~/code/imglib/imglib2
$ mvn install
[INFO] --- maven-install-plugin:2.5.2:install (default-install) @ imglib2 ---
[INFO] Installing /Volumes/code/imglib/imglib2/target/imglib2-5.9.3-SNAPSHOT.jar to /Users/curtis/.m2/repository/net/imglib2/imglib2/5.9.3-SNAPSHOT/imglib2-5.9.3-SNAPSHOT.jar
[INFO] Installing /Volumes/code/imglib/imglib2/pom.xml to /Users/curtis/.m2/repository/net/imglib2/imglib2/5.9.3-SNAPSHOT/imglib2-5.9.3-SNAPSHOT.pom
[INFO] Installing /Volumes/code/imglib/imglib2/target/imglib2-5.9.3-SNAPSHOT-sources.jar to /Users/curtis/.m2/repository/net/imglib2/imglib2/5.9.3-SNAPSHOT/imglib2-5.9.3-SNAPSHOT-sources.jar
[INFO] Installing /Volumes/code/imglib/imglib2/target/imglib2-5.9.3-SNAPSHOT-tests.jar to /Users/curtis/.m2/repository/net/imglib2/imglib2/5.9.3-SNAPSHOT/imglib2-5.9.3-SNAPSHOT-tests.jar
[INFO] --- scijava-maven-plugin:1.1.1:copy-jars (copy-jars) @ imglib2 ---
[INFO] ------------------------------------------------------------------------
[INFO] ------------------------------------------------------------------------
$ cd ~/code/imglib/imglib2-algorithm
$ mvn -Denforcer.skip=true -Dimglib2.version=LATEST install

One way to test it easily afterward is with jgo:

$ jgo net.imglib2:imglib2:LATEST+net.imglib2:imglib2-algorithm:LATEST+sc.fiji:fiji