Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Mark Hiner
    @hinerm
    @tpietzsch would you mind checking out the latest https://github.com/imagej/ij1-patcher and running mvn clean test to see if it works on mac?
    and maybe also repeating for imagej/ij1-patcher@d45f936 ? which I assume will fail because it lacks the mac adapter
    Tobias Pietzsch
    @tpietzsch
    yes to both
    master goes through
    Mark Hiner
    @hinerm
    :+1: thank you!
    Tobias Pietzsch
    @tpietzsch
    The weird thing is that Java 8 complains about the MacAdapter thing
    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
    Mark Hiner
    @hinerm
    @tpietzsch something about MacAdapter is java-8 specific IIRC
    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
    Jan Eglinger
    @imagejan
    :+1: thanks for all of this, @hinerm !
    Mark Hiner
    @hinerm
    hey you fixed it first @imagejan! Sorry I missed your PR
    @tpietzsch I can bump BDV-core to 10.2.0.. are there any other BDV versions you want updated?
    Jan Eglinger
    @imagejan

    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 :-/

    Mark Hiner
    @hinerm

    Also, we should try to catch up with the newer versions up to 1.53g and soon h :-/

    :skull: :skull: :skull: :ghost:

    Jan Eglinger
    @imagejan
    :laughing:
    Tobias Pietzsch
    @tpietzsch
    @hinerm yes bigdataviewer-core-10.2.0
    bigdataviewer-vistools-1.0.0-beta-27
    Mark Hiner
    @hinerm
    @tpietzsch :+1: I'll run a melting pot with those right now
    Tobias Pietzsch
    @tpietzsch
    and I'm releasing bigdataviewer_fiji-6.2.1 now
    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 !
    Tobias Pietzsch
    @tpietzsch
    yes, thanks a lot!!!
    Mark Hiner
    @hinerm
    I wonder if there's a way to detect pinned versions...
    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
    Jan Eglinger
    @imagejan
    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 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).
    Mark Hiner
    @hinerm

    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

    Mark Hiner
    @hinerm

    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).

    totally. I'd be happy just to have the melting pot report if it finds any "Overriding managed version" warnings.

    Tobias Pietzsch
    @tpietzsch
    I'm always confused about this:
    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...)
    Mark Hiner
    @hinerm

    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?

    This is OK with me.

    Curtis Rueden
    @ctrueden
    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.
    Curtis Rueden
    @ctrueden
    @imagejan @tpietzsch @hinerm About where to test big Contexts: I suggest fiji/fiji, and maybe also imagej/imagej. We need to be careful to keep pom-scijava agnostic of Fiji and ImageJ.
    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?