Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Giuseppe Barbieri
    @elect86
    I'm getting some issue with the catalog/platform plugins and I'm updating them right now, and while I was there I've also taken the chance to make them auto-generated automatically from the given/set pom. I'm also testing the new shiny KSP which was just sponsored.
    Also, instead creating an action to check every x minutes about any new commit (in order to trigger a new code generation), may I add it directly into the same repo alongside maven?
    Curtis Rueden
    @ctrueden
    I don't understand what you are asking me, sorry. I read about platforms just now (and before), and just noticed an aspect I didn't mention in the sciview channel before: enforcedPlatform instead of platform when importing pom-scijava. I think probably enforcedPlatform is what is desired. But I don't know what a "dynamic alignment" is (it looks like a Gemfile.lock or package-lock.json but for Java+Gradle?)—I understand the value conceptually to locking down the versions for reproducibility, but don't understand what you mean by it "spared me quite some time". How so? I also don't understand your question about "creating an action" to poll? Are you talking about GitHub Actions?
    Oh, I guess you are talking about polling the pom-scijava repository for changes, and wanting to instead commit something (what?) along side? But why do you need this?
    Giuseppe Barbieri
    @elect86
    do you recall that discussion about updating the versions incrementally?
    Curtis Rueden
    @ctrueden
    I don't, sorry. Versions of what? And what does "updating incrementally" mean?
    Giuseppe Barbieri
    @elect86
    Imagine you want to test the melting pot with some modules/project which are at the base of a huge hierarchy. Like all the scijava-* modules, then you check every test pass and you also check (binary) compatibility between them (this is where you would catch function signature mismatches). Then you publish the new alignment, limited for the moment to this few projects only. Then the same for all the big projects/multi-module, such as fiji, imagej, imgLib2, scifio, etc etc. Then you can publish all of them in the same alignment file (called lockfile) simply by modifying the file itself.
    Then you test the compatibility among all of these big projects and update the lockfile, you can test all the other misc spare libraries altogether or one by one and update the lockfile as you please. You don't have to publish a new pom everytime, you can simply follow the developing updates immediately and publish a new pom release only when you think it's time
    enforcing the bom means that the versions defined in it will override every other inclusion in the dependencies graph. Given usually that the bom lags behind the latest developments, I think this is not what we would like, but I'll double check this
    Curtis Rueden
    @ctrueden
    If I understand what you are saying correctly: we tried to do this with multiple BOMs, one per layer. But it did not work well. Maybe it would have worked better if we had also published a "BOM of BOMs" or overarching BOM that imported all the other BOMs at known-compatible versions.
    Regarding enforcing the BOM: you want to enforce it, except for explicitly overridden versions of individual things.
    I noticed that with platform (not enforcedPlatform), the version of Guava that was brought into sciview was wrong, for example.
    Giuseppe Barbieri
    @elect86

    How so?

    I bump unsigned and publish it, then I update the lockfile (I even do that from the browser interface), then I bump glm which in turns depends on unsigned. Without dynamic-alignment, I should have bumped and published also the platform listing the new unsigned version and then import this finally in the last glm and so on

    I noticed that with platform (not enforcedPlatform), the version of Guava that was brought into sciview was wrong, for example.

    Thanks for noticing, I'll check that as soon as I have a moment

    Curtis Rueden
    @ctrueden
    This sounds like exactly how we do it now: if unsigned and glm were part of pom-scijava, you'd simply bump unsigned in pom-scijava, and you are done. The master branch of pom-scijava now declare the new unsigned with the existing glm, and anyone extending this new pom-scijava would receive those versions (even though glm itself declares an older unsigned version, the BOM overrides it with the newer one, as desired).
    Giuseppe Barbieri
    @elect86
    if unsigned gets a new feature or a bug fix, I don't need to publish a new pom
    Curtis Rueden
    @ctrueden

    and published also the platform listing the new unsigned version

    Yes, that's cutting a new pom-scijava release, indeed.

    and then impmort this finally into the last glm and so on

    You don't have to do that part, though. Anything extending the new pom-scijava will get the new unsigned and the existing glm. Right?

    How does downstream software know it's safe to use the new unsigned, then?
    Giuseppe Barbieri
    @elect86
    tests
    Curtis Rueden
    @ctrueden
    No, sorry, I don't mean "how do we test that it's safe"
    I mean: how does the tooling of a downstream project know that unsigned should be brought in at your newly released version?
    When they are using a BOM that says otherwise?
    Just because you manually say so in this lock file, right?
    Giuseppe Barbieri
    @elect86
    if there are no breaking changes, it's safe to silently update it, otherwise a new release is safer
    Curtis Rueden
    @ctrueden
    That's no different than using a version pin in the pom.xml of a downstream project, if so.
    What I'm wondering is: are you saying there is some common place to put "version pins" of this nature, for e.g. a new unsigned, that does not require publishing a new BOM, but does allow downstream code to in general infer that they can update unsigned? If not, then it's just a manual override per project, fine. Or if this mechanism is general/extensible in that way, then it sounds like just another BOM layered on top of the BOM?
    Giuseppe Barbieri
    @elect86
    you can interpret it as bom hierarchy

    Oh, I guess you are talking about polling the pom-scijava repository for changes, and wanting to instead commit something (what?) along side? But why do you need this?

    I mean merging the current scijava-catalog/platform inside the bom project. So, whenever you add a new commit to the bom, github action may trigger automatically the code generation for gradle as well, propagating the new change immediately. I know this would add quite some files, polluting the repo, so we could think of having everthing inside a dedicated sub-directory, if this may be acceptable for you.. Don't hesitate to say no if you don't feel it

    Curtis Rueden
    @ctrueden
    What I'd rather do is add an action to ping a downstream repository. So that your repo can build in response to pom-scijava pushes.
    Giuseppe Barbieri
    @elect86
    also, I need to look into that though. Never done before
    but I know there are some manual webhooks
    Curtis Rueden
    @ctrueden
    One easy way is for the pom-scijava build to just push something to your repo. Whatever makes sense.
    Giuseppe Barbieri
    @elect86
    I think the right way is using a webhook event, I'd try this first
    Curtis Rueden
    @ctrueden
    Giuseppe Barbieri
    @elect86
    cool, thanks
    Curtis Rueden
    @ctrueden
    And I guess this action might be useful in combination with it: https://github.com/peter-evans/repository-dispatch
    I think the peter-evans action makes this a lot simpler.
    Giuseppe Barbieri
    @elect86
    yep, I think so too
    Giuseppe Barbieri
    @elect86
    I see you already pushed the new naming convention, nice
    Giuseppe Barbieri
    @elect86

    is there a reason why this

                    <artifactId>3D_Blob_Segmentation</artifactId>
                    <version>${sc.fiji.Fiji_3D_Blob_Segmentation.version}</version>

    isn't sc.fiji.3D_Blob_Segmentation? Because of the leading digit?

    Giuseppe Barbieri
    @elect86
    also, why this is padded with ImageJ_ instead Fiji_?
                    <groupId>sc.fiji</groupId>
                    <artifactId>3D_Objects_Counter</artifactId>
                    <version>${sc.fiji.ImageJ_3D_Objects_Counter.version}</version>
    Curtis Rueden
    @ctrueden
    @elect86 Thanks for catching those mistakes! I guess the thinking was that having properties starting with numbers is not OK. But I just tested it, and Maven seems to allow it just fine. So I think those prefixes were always(?) unnecessary. And should certainly be removed at this point.
    Giuseppe Barbieri
    @elect86
    np
    Ps: I was trying to move scijava-catalog and platform from a custom github repo to the gradle portal, but they rejected their id (scijava-) because it doesnt match the organization (scenery). May I move those repo under the scijava organization to try and see if then they'll get accepted?
    Curtis Rueden
    @ctrueden
    Feel free to transfer them to the scijava org if it helps you. I can approve the transfers, and make sure you have admin access to them.
    Giuseppe Barbieri
    @elect86
    thanks
    @skalarproduktraum, I don't have anymore root priviledge on them since they have been moved to scenery, could you help me?
    Curtis Rueden
    @ctrueden
    Giuseppe Barbieri
    @elect86
    super fast, nice
    Ulrik Günther
    @skalarproduktraum
    @elect86 what do you need transferred to the scijava org?
    Giuseppe Barbieri
    @elect86
    let's start with scijava-platform
    Nicolas Chiaruttini
    @NicoKiaru
    @imagejan is there a way to make a certain scijava parameter from a certain class batchable ? I would like to have every command with a SourceAndConverterinput parameter executable in batch mode. I already have a widget for SourceAndConverter[].
    Jan Eglinger
    @imagejan
    @NicoKiaru yes, of course! :smile: You need to implement BatchInputProvider; see FileBatchInputProvider and DatasetBatchInputProvider for examples.