Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Jean-Yves Tinevez
    @tinevez
    I could do this this July
    I suggest we retire IEP immediately in the inteval which will allow removing JEP
    Jean-Yves Tinevez
    @tinevez
    It will be fun
    Philipp Hanslovsky
    @hanslovsky
    It seems that https://maven.scijava.org/ is down. I cannot access it from my laptop and neither can jitpack.io
    Jan Eglinger
    @imagejan
    again? yes, confirmed here...
    Philipp Hanslovsky
    @hanslovsky
    Confirmed here as well
    Jan Eglinger
    @imagejan
    thanks @hinerm for bringing it back again!
    Curtis Rueden
    @ctrueden
    It's both amusing and horrifying that every time the Nexus goes down, someone pings about it on Gitter before I see the email from the failed status check, even though the status checks have 15-minute granularity...
    Jan Eglinger
    @imagejan
    :laughing:
    Philipp Hanslovsky
    @hanslovsky
    Just shows the impact of SciJava. A lot of things wouldn't work without itit ๐Ÿ‘
    Stephan Saalfeld
    @axtimwalde
    :thumbsup:
    Gabriel Selzer
    @gselzer
    @ctrueden is there a location in pom-scijava where the scijava annotation processor is called? If not, how is it run? I cannot seem to find it...
    Curtis Rueden
    @ctrueden
    @gselzer The javac tool calls registered annotation processors automatically, for those on the build-time classpath. So you won't see scijava-common registered as dependency of the maven-compiler-plugin in pom-scijava-base.
    Philipp Hanslovsky
    @hanslovsky
    If anyone is interested in using github actions, here is what I did for nta.kt (so far):
    I tested github actions and now ntakt automatically creates a release with resources attached whenever a tag of the form ntakt-${VERSION} is created and ${VERSION} is the same as version in gradle.properties. Right now, these tags have to be created manually still, but I don't think it should be too hard to automatically create them when version is not a snapshot in gradle.properties. Ideally, the version would also be determined automatically through tags in PR comments but that is relevant. For reference, these are the workflows
    Curtis Rueden
    @ctrueden
    Thanks, @hanslovsky. @hinerm Pass this along to Jack?
    Right now for SciJava projects on Travis, we don't bother with checking the pom.xml version for matching the tag, although this is a good idea.
    Philipp Hanslovsky
    @hanslovsky

    My reasoning is that there should be one source of truth and I have this workflow in mind:

    1. make changes only through PRs, PR tags indicate major/minor/patch changes
    2. trigger release somehow (???) that creates an appropriate release version commit and a bump commit for next development cycle
    3. automatically create tags when version in pom.xml/ properties.gradle is not a snapshot
    4. create a release and attach artifacts (jar, pom) to it; optionally: publish to scijava maven repo

    Out of these, (2) is still totally unclear to me. (4) is already implemented, and for the others I have some vague ideas how that could work.

    Curtis Rueden
    @ctrueden
    You don't like running a script?
    Philipp Hanslovsky
    @hanslovsky
    Running a script is fine but it requires that the master/main branch is not protected, conflicting with strict enforcement of (1)
    Curtis Rueden
    @ctrueden
    Why? What if it just made the tag and pushed that? And then the triggered CI build took care of pushing to master? And only it had permission?
    Philipp Hanslovsky
    @hanslovsky
    If that is possible, that would work :thumbsup:
    Curtis Rueden
    @ctrueden
    It means your CI needs push permission, which is maybe a security issue. *shrug*
    But it already has deploy permission, so... probably fine?
    Philipp Hanslovsky
    @hanslovsky
    I think so
    Philipp Hanslovsky
    @hanslovsky

    I updated the GitHub action:

    • single workflow
    • tag/release with jar and pom is created for non-snapshot version that matches ^[0-9]+\.[0-9]+\.[0-9]$ (only on main branch)
    • non-snapshot version triggers new commit and push that bumps the patch version to next development cycle and adds -SNAPSHOT.
    • Simple push a non-snapshot version commit to master, and a release + bump to next development cycle will happen automatically! The development-cycle bump commit will not trigger github action, though.
    • version in gradle.properties is single source of truth for version, tag follows suit
    • still cannot do push protected main branch because github actions need to push to branch to bump next development cycle (maybe a PR would be better and more defensive anyway - there could be commits in between)

    Overall I am quite happy with the workflow. With some clean-up, this may be standardized and provided on GH marketplace
    Wish list:

    • Create release PR with button click in github UI
    • Auto-generate new version suggestions based on tagged PR messages since last tag
    Jan Eglinger
    @imagejan
    @hanslovsky that looks great!
    Would be nice to make it run with the default branch, no matter if itโ€™s named main or master or something else.
    (The latest travisify.sh contains changes in a similar direction, to support other names than master, maybe the logic can be copied from there.)
    Curtis Rueden
    @ctrueden
    @hanslovsky Since you are using Gradle now: a couple of things to think about from the SciJava perspective going forward. We need a pom.xml generated, and: 1) Stored inside the JAR file in the same place Maven would put it (META-INF/maven/groupId/artifactId/pom.xml); 2) Deployed to the Maven repository along with the binary artifacts. Without these two things, lots of downstream tooling and workflows will break. For example, the new wiki's statboxes that automatically retrieve info from the latest release of an associated G:A will not function.
    The unified format of the pom.xml really is wonderful for automation and tooling, and alternate build systems Gradle, Lein, etc., lose a lot of they cannot produce a pom.xml compliant with SciJava requirements.
    (CC @elect86, who has done a bunch of exploration of how we might migrate core SciJava to Gradle builds)
    Philipp Hanslovsky
    @hanslovsky
    Do you know what needs to be added to pom.xml generated by publishToMavenLocal to be compliant with SciJava?
    Giuseppe Barbieri
    @elect86
    why is 1 necessary? There is the pom.xml published alongside the artifact..
    Philipp, given the basic support of boms in gradle, I've been porting the scijava pom to gradle, take a look at the catalog and platform
    Curtis Rueden
    @ctrueden
    (1) is necessary because we have tooling in ImageJ that reads POMs out of JAR files, so that you can reason about the various metadata of a given class/package/component.
    See here for code.
    @hanslovsky Here is the summary of the requirements.
    Philipp Hanslovsky
    @hanslovsky
    Adding pom.xml to the artifact should be a relatively simple gradle task.
    Thanks!
    Philipp Hanslovsky
    @hanslovsky

    I have now the following workflow using github actoins:

    1. Create release request issue (from an issue template) (manual)
    2. github actions creates PR and closes this issue, with
    3. Merge PR (manual)
    4. Create PR with bump to next dev cycle

    (4) uses a PR so main branch can be protected.
    I am quite happy with the flow now.

    Curtis Rueden
    @ctrueden
    Thanks for the update @hanslovsky. I wish (4) weren't necessary, because it seems overcomplicated and you can imagine things going wrong with it in practice. What if someone merges a different PR before the bump-next PR? Then you'd have new snapshots deployed with the old version number. But I guess this is a minor issue.
    Philipp Hanslovsky
    @hanslovsky
    @ctrueden I share the same concern about (4) and might have a surprise for you soon (I will keep you posted).
    Stephan Saalfeld
    @axtimwalde
    This message was deleted
    Philipp Hanslovsky
    @hanslovsky
    Step (4) is obsolete now because (2) also creates a second commit with bump to next development cycle. Details here. I might make a short screen cast if I find some time on the weekend. I think that is a pattern that could be generally adopted after some fine-tuning.
    Philipp Hanslovsky
    @hanslovsky
    The name for scijava CICD scripts repo could be sCIjava :laughing: Or sCICDjava to avoid name-clashes with scijava
    NicoKiaru
    @NicoKiaru
    @hinerm thanks for the merge on scijava-persist and thanks @gselzer for the discussion and fixes! I hope it can be useful. I won't have time to work on it before September, but if anybody's interested please have a look and give your opinion
    Gabriel Selzer
    @gselzer
    No problem, very happy to help @NicoKiaru!
    There's actually a chance we might use scijava-persist in SciJava Ops - @ctrueden and I were talking about being able to serialize Op execution chains
    Jan Eglinger
    @imagejan

    From Travis:

    Since June 15th, 2021, the building on travis-ci.org is ceased. Please use travis-ci.com from now on.

    @ctrueden Should we move remaining projects to travis-ci.com as long as GitHub actions are not yet set up for SciJava-related projects?

    Curtis Rueden
    @ctrueden
    @imagejan Wow, they finally ended it?
    I think, then, we need to refocus on migrating to GitHub Actions now.