Process to simplify adding an external dependency

Tags: #<Tag:0x00007fd5484d7e28> #<Tag:0x00007fd5484d7a40>


Hi all,

So I have been playing with GPars a parallelization library for groovy, which is not bundled with Fiji at the time.

I don’t want to set up an update site, as it is not my project to distribute, but was wondering what was the easiest way to get users to install this dependency in Fiji?

While I realize that copy-pasting a single file into Fiji’s jars folder does not constitute a task where sweat and blood will be shed, I just wanted to get people’s opinions.

All the best


Hi @oburri,

Is it possible to create parallel streams like in Java ? Looks very cool!

Apparently GPars should be included within groovy since version 1.8:

Fiji provides the version 2.4.8… but GPars is not included! Why ? I understand that it’s because groovy declares this dependency as optional ( and

So unfortunately this dependency has to be declared explicitely (for instance in an ij2 java project uploaded in an update site).

I just discovered this library thanks to you, but in my opinion this library is useful in general for groovy scripting, independently of any plugin / update sites. I would thus vote to add it as a dependency directly in scijava. Somewhere here ?

Maybe create a PR ? But then who is suppose to decide whether to include it or not ? @ctrueden ?

I suppose one drawback of adding it is that it will make Fiji heavier by about a 1MB. If only 5 people use it, is it worth it ? And who’s deciding ? We vote ? Personally I’d vote for. I’d love to parallelize my groovy scripts, without having to drag and drop a jar file or having to activate an update site.

Outside of this specific gpars case, IMHO, I would not choose this option:

  • I feel that it is unreliable in the medium/long term
  • If you need to reinstall / or install fiji somewhere, you may forget to add this jar
  • since IJ is very active, I’m worried that putting such a “lonely” jar could break other dependencies in a rather incomprehensible way when Fiji is updating

BUT, if it’s for a quick and dirty test, I’d definitely do it! Otherwise I’d choose the complex option: an update site with my personal customizations. I’d share this to anyone interested in some fancy exotic libraries.

Not sure I answered exactly your questions, but anyway, I learned many things :wink:




It probably can. So far I am using it simply to make most things parallelizable as per the example here PerkinElmer Operetta CLS Importer And Groovy Parallelization (shameless self-quoting)

This should probably be discussed at some point how it would make sense. Making a PR would make sense, but the choice could be community-driven, as most things already are :slight_smile:

Thanks again for the complete answer. For plugins it’s easy as you say, but for things that are groovy scripts… I guess discussion is the current way to go.


I added gpars as a runtime dependency to scripting-groovy as @NicoKiaru suggested, and released scripting-groovy 0.2.7. I also bumped the version in pom-scijava. Once a new pom-scijava is released and fiji is updated to use it, the gpars dependency will become part of Fiji.

I don’t understand what you mean by “not my project to distribute.” The GPars project is licensed under the APLv2, so you are free to redistribute it. The correct thing to do, if your update site uses a third party library, is to upload that library to your update site along with your plugin(s)/script(s). Equally correct would be to request that the library be added to the Fiji distribution—especially if your update site requires Fiji regardless. There is currently no formal process for getting a third party library added to Fiji.