A plugin framework and application container with built-in extensibility mechanism.
and maybe also repeating for imagej/ij1-patcher@d45f936 ? which I assume will fail because it lacks the mac adapter
master goes through
Java 11 does not
has the output from both java versions (on imagej/ij1-patcher@d45f936)
For Java 11, some tests go through, e.g.
[INFO] Running net.imagej.patcher.LegacyHooksTest
[INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.713 s - in net.imagej.patcher.LegacyHooksTest
For Java 8, the same test fails
[INFO] Running net.imagej.patcher.LegacyHooksTest
java.lang.RuntimeException: Found incompatible ij.IJ class
at net.imagej.patcher.LegacyEnvironment.initialize(LegacyEnvironment.java:112)
at net.imagej.patcher.LegacyEnvironment.applyPatches(LegacyEnvironment.java:494)
...
Caused by: java.lang.IllegalArgumentException: No such class: MacAdapter
at net.imagej.patcher.CodeHacker.getClass(CodeHacker.java:878)
at net.imagej.patcher.CodeHacker.getMethod(CodeHacker.java:904)
at net.imagej.patcher.CodeHacker.getBehavior(CodeHacker.java:894)
at net.imagej.patcher.CodeHacker.insertAtTopOfMethod(CodeHacker.java:157)
... 35 more
Caused by: javassist.NotFoundException: MacAdapter
at javassist.ClassPool.get(ClassPool.java:430)
at net.imagej.patcher.CodeHacker.getClass(CodeHacker.java:873)
... 38 more
[ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.287 s <<< FAILURE! - in net.imagej.patcher.LegacyHooksTest
Super weird
but I can't find the code that suggests that
anyway I'm releasing a new ij1-patcher and this will all be happier in the next pom-scijava
currently waiting on trakem2/TrakEM2#28 and PreibischLab/multiview-reconstruction#32
@tpietzsch I can bump BDV-core to 10.2.0.. are there any other BDV versions you want updated?
no need to apologise! If I remember correctly, Curtis tried to keep ij1-patcher compatible to as many versions of ij.jar as possible, i.e. also for older versions. I think that’s not really tenable with the latest package changes of MacAdapter and other changes in IJ1. But I think the current ij1-patcher at least doesn’t throw errors when used in non-headless mode with older versions of ij.jar.
Also, we should try to catch up with the newer versions up to 1.53g and soon h :-/
bigdataviewer-vistools-1.0.0-beta-27
that would be also good, if you can still get it in
(but this is not that important, nothing should depend on bigdataviewer_fiji)
so bigdataviewer_fiji-6.2.0 would be fine too
thanks for all of this, @hinerm !
melting-pot is nice for testing, but I feel like it would be helpful if we had PRs to scijava-common whenever people had to pin versions
Hm, sometimes you need to pin to a newer version of a dependency, but you wouldn’t like to have that in pom-scijava immediately, because it might break other dependencies, no? On the other hand, having a bot that creates a new PR to pom-scijava whenever you release a component that has a pinned (newer overridden) dependency would be handy…
But I think already having automated mega-melt being run for every PR to
But I think already having automated mega-melt being run for every PR to
pom-scijava will be a good thing. I see no problem with developers filing PRs “manually” for concerted updates of groups of components (e.g. the n5 ecosystem, ot the BDV ecosystem).
but you wouldn’t like to have that in pom-scijava immediately, because it might break other dependencies, no?
In general, pinning to dependencies is a very bad thing that we should strive to avoid, because we only get to put one version of everything on core Fiji - being whichever version is in pom-scijava
Making a change in pom-scijava that breaks other things is not a bad thing. As long as we're testing with melting-pot before uploading, we aren't going to break Fiji
But I think already having automated mega-melt being run for every PR to pom-scijava will be a good thing.
This would be fine but I don't think we need to reject a change because it breaks something else. Others may disagree, but personally I just care that everything is coherent at release time
Is it ok to file a PR to pom-scijava for updating, say bdv as a group of components, even if I haven't checked that this works with the melting-pot on the rest of pom-scijava?
(I often refrained from doing that, except when I had explicitly checked or was "certain" that there were no API changes...)
My two cents on pom-scijava: I agree with @hinerm. Things being coherent at release time is of course most important. Also crucial is having a good process to continually improve the software, in a way that balances convenience/speed (for developers) and robustness (for users). One thing I'd add is that we need to move more toward not breaking public API. Every time we do it, it ripples through the community for years. For Fiji to improve its reputation among users, we need to get closer to ImageJ1's adherence to stability. New functionality and API are fine, but removing old behavior is not. If API needs to change, we need to use a new package prefix i.e. "generation" of the software, a la Apache Commons Math 2 vs. 3 (or ImgLib1 -> ImgLib2). A more coherent package naming convention will help with this, as will advancing to Java 11 with JPMS where we can restrict which packages are actually part of the public API.
I also agree that we need to be more proactive about avoiding component version overrides in downstream POMs of projects that are part of the SciJava component collection. Otherwise, like Mark said, the "Fiji can only ship one version of each thing" issue rears its head.
It's also super bad if anyone depends on your component. Suppose your project Spifftastic v1 overrides guava to v100, but the latest pom-scijava v30 defines guava at v25. Then downstream, my project CurtisJ extends pom-scijava v30 while depending on Spifftastic v1... I'll inherit guava v25, not guava v100, and Spifftastic won't actually work.
About ij1-patcher and ij1 versions: does anyone have a more maintainable idea for dealing with the imagej-legacy support? I have the feeling that we should put it some effort to reduce the amount of code patching going on—at least at runtime. We could return to a hybrid model where ImageJA is a separate JAR file, which includes patches on top of ImageJ1 managed by git... but we'd still need javassist to patch the headless stuff, unless we maintain two forks of ImageJ1. Thoughts?
The downside of this approach is that we'd really be forking ImageJ1 then, which is something we worked hard for years not to do... 😖