The goal is to let you compile and run unit tests for all your stuff in one go. So you actually unit test at runtime what (e.g.) ImageJ users will have at runtime.
And it frees you from the (untenable) burden of needing every component to always be pinned against its latest upstream dependencies.
In general, there is a dichotomy/conflict between compile time—when you want to ensure building works against the oldest compatible/required version—and runtime—when you want to test again the newest compatible/available version.
I would caution against doing "staged" releases of things locally, or anything like that.
Just test against a big ol' bag of SNAPSHOTs—that's what they are for.
@ctrueden I know that you made meting-pot but I never used it
Yeah, I haven't used it a lot either. There are integrations tests with cram in the repo, so I know it works (at least ostensibly).
We planned to set up a Jenkins job to do it for all of ImageJ2 core, and all of Fiji.
But I never got around to it.
But it sounds like exactly what you need, given your comments above.
The only other thing we are missing is a way to cut multiple releases at the same time. There are lots of edge cases with that though, which make it harder to automate well.