Updating jgrapht-0.8.3.jar to a newer version?



Hello everybody,
we are in term of releasing a new plugin which currently relies on the jgrapht-core-1.2.0.jar library. This library and jar, respectively, seems to be the successor of the jgrapht-0.8.3.jar which is by default deployed in Fiji via the core Fiji update site. Unfortunately the internals of the library changed significantly over time and both jars are incompatible in some parts. I don’t know where and how intensively JGraphT is currently used within Fiji (at least Trackmate seems to rely on it…). So, does anyone know for which part of Fiji the jar is required, and are there any plans to update the jgrapht-0.8.3.jar on the Fiji site to a newer version in near future?

Thanks and best regards,



Hi @bimoelle

Yes TrackMate and MaMuT at least rely on it.
If the internal changed, I will have to make significant changes to both these plugins so as to rely on jgrapht-core-1.2.0.

The problem is that I am currently struggling with time and have a very list of TODO items already overdue. Please be patient.


Hello @tinevez,
thanks for your quick reply. For the moment we will try to offer a workaround to our users to avoid breaking Fiji installations due to conflicting jars when activating our update site. Nevertheless it would really be great if you can find the time in near future to work on the update.

Thanks in advance and best regards,



I had a crack at it and updated TrackMate (on the update-jgrapht branch) to depend on the latest jgrapht-core-1.3.0. Here’s the current diff:

It compiles and all tests still pass, but I didn’t test any further, and in particular am not sure if the directed/undirected graph stuff still works as intended (DirectedGraph and UndirectedGraph were replaced by a single Graph interface).

It’ll need some testing, but if this works, and if similar changes are made in trackmate-core, trackmate-extras, MaMuT and probably other components, we can go ahead and submit a PR to pom-scijava to change the dependency to the new groupId and version.

@bimoelle I’m sure you’re welcome to submit PRs to the affected repositories to speed up the process :wink:

I’m not a Maven expert, but you could try using the maven-shade-plugin to achieve this goal. From the plugin description:

Apache Maven Shade Plugin

This plugin provides the capability to package the artifact in an uber-jar, including its dependencies and to shade - i.e. rename - the packages of some of the dependencies.


Hi @imagejan,

sounds great, thanks a lot! :smiley:

Indeed, I’m not averse to support the update process :slight_smile: Working around the incompatibility is really just a more or less bad compromise solution for us, and if it’s possible to overcome it soon, that’s great.
Anyway, just replacing data types and updating the code is one thing, but making sure that everything works correctly is another. I never used TrackMate so far, so I could only rely on provided tests. But, I will have a look.

Thanks for the hint, we will check if this might help.




Would you care to run some tests to confirm that nothing changed in the functionalities?
On my side I will try to rerun the ISBI challenge SPT tests to make sure the trackers are no affected.


I’ll try, as soon as I find the time :slight_smile:

We could also take the chance and implement a code coverage tool into our Travis CI builds, so we get an idea of which parts of the code are covered by the existing unit tests.

Would you mind if I play around with https://codecov.io/ and the JaCoCo or Cobertura maven plugins (again, when I find the time…)?


Please do!
Please do!
Please do!


I scanned the pom files of the projects from the Fiji organization Github repo for JGraphT dependency. If I did not accidentally miss a dependency the following four projects should be the only ones relying on JGraphT:

  • MaMuT
  • TrackMate
  • TrackMate-examples
  • trackmate-core

These are the ones that you already mentioned for updating. Other components relying on JGraphT do not seem to exist in the core Fiji repositories.




Using the GitHub button on search.imagej.net, I also got imagej/trackmate-ops that is using jgrapht classes but apparently doesn’t declare this direct dependency in its pom.xml.

Oh, and then there’s some code on @tinevez’s personal GitHub space:


The imagej/trackmate-ops project declares the TrackMate project itself as one of its dependencies, hence, inherits JGraphT implicitly as transitive dependency.


Yes, but since it uses some jgrapht classes directly, it should declare a direct dependency instead of relying on the indirect one. Otherwise, the code will break when TrackMate is bumped to a newer version…


Yes, I agree. Declaring the dependency explicitly would be more safe in this case.


I would like to work on this and make sure that EVERYTHING works first. That is

  • TrackMate
  • MaMuT
  • TrackMate-TrackAnalysis
  • trackmate-ops (might have to talk to @dietzc about this)
  • TrackMate-examples
  • trackmate-core

Then we would have to change the version number of jGraphT in the pom-scijava, the re-release TrackMate against this parent.

What do you say @imagejan @ctrueden @bimoelle ?


Another user of jgrapht:


Varun @kapoorlab can you join the discussion?


I did a quick test on MTrack, it seems fine for now.


Hello @tinevez,
sounds reasonable. If you think it might help I could give it a try to update for example the source code of the TrackMate-examples or another of the repos (… taking the changes @imagejan did to TrackMate as template). Just let me know how I can best support the process.



Did you test with jgrapht-core and the new groupId (org.jgrapht instead of net.sf.jgrapht)? I submitted a pull request with the necessary changes to make the build pass:

I didn’t do any functional testing though, and AFAICT there are no unit tests in the repository, so please test before merging :wink:


Thanks alot @imagejan, I checked and made some changes and committed/released a new update for MTrack, it seems fine with the new changes.