Make it possible to build QuPath with Fiji dependencies #1728
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
PR drawing heavily on @ctrueden's work - especially https://forum.image.sc/t/embedding-fiji-inside-qupath/105065
This adds support for launching QuPath from gradle with
to bring in Fiji & its dependencies in a way that makes it possible to work with a 'full' version of Fiji from within QuPath, rather than ImageJ. Using
defaults to 'regular' QuPath with ImageJ.
It's also possible to build the (large) self-contained packages with
or, faster with
at the expense of omitting the dependency license report.
We don't have plans to distribute a QuPath+Fiji build at the moment - rather, this is intended for power-users who create the builds themselves for their own use. Although with Gradle that should be pretty easy, as long as you have Java 17+ installed (Java 21 preferred).
Big caveat
It's currently only possible to launch Fiji once from within QuPath: if you close it, then the next time you try to open it you'll get a more standard ImageJ without many extra plugins. I haven't figured out how to get Fiji back, or to prevent it being disposed in the first place.Reopening Fiji should now workSmall caveats
Dependency resolution is left up to Gradle; it's not guaranteed that QuPath will behave identically when launching in this way - and there might be commands in either Fiji or QuPath that don't work as expected.
Although that also means that QuPath's script editor will auto-discover and add support for a few more scripting languages.
And Fiji's will be equipped with Groovy 4 instead of Groovy 3.