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
    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?
    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... 😖
    Jan Eglinger
    @imagejan

    Thanks Curtis for the comments.
    Maybe we can set up a bot (or use dependency-bot) that opens a new PR to ij1-patcher whenever a new ij.jar version is released, with pinning to that newer version? Then at least, we’re immediately aware of new issues introduced by changes in IJ1 (except e.g. Mac-specific things like MacAdapter, but at least all those headless-breaking changes).

    I agree forking ImageJ1 would be too disruptive for the community, many people rely on Help > Update ImageJ… bringing in the latest daily build of ij.jar.

    Curtis Rueden
    @ctrueden
    For Help > Update ImageJ... we could override it to download versions of ImageJA/ImageJA-headless instead. And backport all the patches across all the versions of ij, and deploy all to OSS Sonatype. It would be upfront effort, but once done, perhaps simpler to maintain that what we have now. I'm not pushing strongly for it though, just trying to stimulate thought and discussion.
    Jan Eglinger
    @imagejan
    Hm ya… I guess we’d still be lagging behind daily builds quickly, unless there’s someone 100% dedicated to follow up with patches.
    Curtis Rueden
    @ctrueden
    That's true, it would break daily builds.
    But they are broken now anyway, eh?

    Related question: starting tomorrow I'll have two days a week to work on ImageJ again... but of course I need to prioritize what I work on in those limited windows. I was considering creating a poll where people can vote on what's most pressing for them? Things like:

    • PyImageJ + ImageJ1 tutorial notebookJ
    • Fix ij1-patcher with latest ij1 versions
    • Finish new ImageJ website
    • Migrate core builds from Travis CI to GitHub Actions and update community process
    • Work on merging existing PRs
    • Write up strategic vision + technical directions of next 1-3 years
    • Finish reconciling ImageJ-OMERO and ImageJ Server with PSJ 30+.

    • <your favorite project here>

    Jan Eglinger
    @imagejan

    @ctrueden wrote:

    But they are broken now anyway, eh?

    Only for headless usage, so most users don’t see they’re broken ;-)

    Curtis Rueden
    @ctrueden
    Anyone here have a particular vote? Or comments on whether it would be good or bad to make such a poll on the forum?
    Ah, right.
    Jan Eglinger
    @imagejan
    I vote for all of them :laughing:
    Serious: focus on what no-one else can do. (e.g. ij1-patcher is probably less urgent; or someone else can fix if they need it)
    yeah, why not poll..?
    Curtis Rueden
    @ctrueden
    :stuck_out_tongue_winking_eye: That has historically been my attitude as well! But trying to do everything (badly) has gotten us to where we are today, which I am not super satisfied with. Thanks for the reminder about doing what others can't—that's good advice. Regarding the poll: any other urgent pain points I forgot, which should go on the list of options?
    Jan Eglinger
    @imagejan
    What comes to my mind is mostly compatible with your "Work on merging existing PRs” part:
    • have an eye on the recent autocompletion improvements in script-editor (and comment how they generalize from Jython to other script languages)
    • scijava-ui-swing-related stuff (dynamic change of choices, number format, widget style fixes, etc.)
    • some open issues in scifio
    Curtis Rueden
    @ctrueden
    https://forum.image.sc/t/which-imagej-related-tasks-would-help-you-the-most/48041
    NicoKiaru
    @NicoKiaru
    Do you know how to display a useful message when the enforcer fails ? My google skills are not good enough for that question
    Curtis Rueden
    @ctrueden
    @NicoKiaru In my opinion, the enforcer already displays a useful message when it fails. It tells you which rule, and in many cases, details of how/where. Could you please paste an example of a failure that you feel is not useful? Then we can discuss how to improve it.
    Curtis Rueden
    @ctrueden
    If you are wondering where the messages are configured: here are a couple of examples from pom-scijava-base.
    NicoKiaru
    @NicoKiaru
    Ahah, dumb me, it's because I didn't know where to look in intellij, it's in the Run tab: