Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Curtis Rueden
    @ctrueden
    @elect86 Yep, that is the goal. If you see otherwise, let me know. This is vital for the melting pot tooling I wrote to be able to override versions of things from the CLI.
    There is one exception on the horizon: some components have clashing artifactId, with distinct groupId. We need a strategy for naming the properties unambiguously in that case.
    Giuseppe Barbieri
    @elect86
    for example?
    Curtis Rueden
    @ctrueden

    The current offenders are:

    antlr:antlr:2.7.7 & org.antlr:antlr:3.5.2
    com.opencsv:opencsv:5.2 & net.sf.opencsv:opencsv:2.1
    net.sf.trove4j:trove4j:3.0.3 & org.jetbrains.intellij.deps:trove4j:1.0.20181211
    net.sourceforge.findbugs:annotations:1.3.2 & org.jetbrains:annotations:13.0
    org.jocl:jocl:2.0.1 & org.jogamp.jocl:jocl:2.3.2

    Therefore, I'm thinking something like:

    <dependency>
      <groupId>antlr</groupId>
      <artifactId>antlr</artifactId>
      <version>${antlr.antlr.version}</version>
    </dependency>
    <dependency>
      <groupId>org.antlr</groupId>
      <artifactId>antlr</artifactId>
      <version>${org.antlr.antlr.version}</version>
    </dependency>
    And then maybe something like:
    <properties>
      <antlr.version>2.7.7</antlr.version>
      <antlr.antlr.version>${antlr.version}</antlr.antr.version>
      <org.antlr.antlr.version>3.5.2</org.antlr.antlr.version>
    </properties>
    I.e.: only one of the antlr artifacts would be the "default" one which gets overridden by a simple -Dantlr.version=... setting.
    @elect86 What do you think? Would it work for you?
    Giuseppe Barbieri
    @elect86
    the first part is also like I'd have done it
    Curtis Rueden
    @ctrueden
    The second part lets us keep backwards compatibility with the old way, while now having unambiguous properties for all artifacts in future.
    Giuseppe Barbieri
    @elect86
    second is up to maven only, so I don't have preference.
    However if you really ask me, unless they keep introduced at the very same time, also the second one makes sense
    Curtis Rueden
    @ctrueden
    I have been meaning to ask: how am I going to test scenery and sciview in the mega-melt? Is it possible to pass overridden version properties like -Dfoo.bar=1.2.3 on the CLI to a gradle build?
    Giuseppe Barbieri
    @elect86
    yes, if I recall it right, cli args gets the priority
    Curtis Rueden
    @ctrueden
    OK, great, I can test it. But is the sciview build.gradle.kts now good with the pom-scijava BOM import I pasted awhile back? Or is that still needing to be done?
    Giuseppe Barbieri
    @elect86
    btw, since we are at, let me just tell you that I have been successfully using a dynamic alignment since a while now and I can tell you has spared me quite some time
    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