so we need a “high-level” context creation test as well
This should implicitly happen in the melting pot. But the problem we ran into here isn't specifically about context creation. Any test in imagej-legacy or downstream I would expect to hit this exception.. but as you noted, nothing is testing on mac
to which repository should I add the test?
@tpietzsch I'm sorry, I just wanted you to add the test to the bdv-fiji branch to complete the MCVE. But since we identified the problem and have now fixed it (imagej/ij1-patcher@0f3c057) I don't think we need to add a test anywhere
mvn clean testto see if it works on mac?
[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
[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
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
Also, we should try to catch up with the newer versions up to
1.53g and soon
thanks for all of this, @hinerm !
pom-scijavawill 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
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