Open source scientific multidimensional image processing
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.
It's really up to you, if you want to cede some creative control, or if you want full control.
it does indeed
Well I want to make it easly accessible so an "official" plugin is better in my opinion
So then you have two choices: "standard" or "external"
"external" gives you more control, whereas "standard" makes less work for you.
and I don't think I'll loose control on it or if I do that will be for the best I guess
hum what is the difference for the end user ?
does they have to enable update site ?
Well, by "cede control" I mean: someone else might cut a release of your plugin. Your master branch should be release ready all the time. Etc.
Standard and external are both explained at the link above.
Ok then a standard plugin is ok for me
If standard, it lives at https://github.com/fiji and has sc.fiji groupId. The maintainers can push commits, cut releases, etc.
If external, you keep in your org. Different groupId. No one but you (unless you desire otherwise) can push commits etc. Fiji maintainers need to file PRs.
The downside is that if we need to make a change to bring your plugin up to compatible again with the latest stuff, then there might be a delay on you merging it, leaving users with a broken version of your plugin for days or weeks.