Version stored in .module doesn't match pom version for use with Gradle

[petebankhead]

Very possible this is an issue of me not understanding, but I'm unable to access the version catalog in Gradle with the error

Could not resolve all artifacts for configuration 'incomingCatalogForSciJava0'.
> Could not find pom-scijava-19.0.0.toml (org.scijava:pom-scijava:39.0.0).
  Searched in the following locations:
      https://repo.maven.apache.org/maven2/org/scijava/pom-scijava/39.0.0/pom-scijava-19.0.0.toml

Checking pom-scijava-38.0.1.module I see

{
  "formatVersion": "1.1",
  "component": {
    "group": "org.scijava",
    "module": "pom-scijava",
    "version": "19.0.0",
    "attributes": {
      "org.gradle.status": "release"
    }
  },

which seems to be the version of pom-scijava-base (19.0.0) and not of pom-scijava (38.0.1).

Since the logic for setting the version in build.gradle.kts is

version = File("../pom.xml").readText().substringAfter("<version>").substringBefore('<')

is this an error that occurs because of the order in which versions appear in the xml?

(The bigger picture: I'm having problems using scijava-pom for dependencies with native libraries, because it uses profile activation based on os.family and it seems Gradle doesn't support that - so I was hoping that a switch to use the version catalog here might help me figure out a workaround)

Thanks!

[ctrueden]

@petebankhead Thanks a lot for trying out the Gradle catalog! Much appreciated. 👍

I guess you are the first person to try using it in practice, because this is clearly a major error. I think your diagnosis of the issue is correct. It's too late now to fix the 38.0.1 or 39.0.0 pom-scijava releases, but I fixed the logic for the next release (8d52f8b). I will release version 40.0.0 ASAP, but in the course of testing this I found that I had neglected to reenable pom-scijava's integration tests for the past few weeks, so now they need to run (which can take hours), and then I need to fix any newly uncovered problems, before I can release 40.0.0. I'll keep you posted.

[ctrueden]

The issue with native library dependencies is something @elect86 was previously thinking about how best to address. Related issues and repositories: #241, scijava/pom-scijava-base#30, os-maven-plugin, native-lib-loader, scijava/native-lib-loader#50.

[ctrueden]

I've released pom-scijava 40.0.0 to OSS Sonatype; should be mirrored to Maven Central within the next few minutes. I'll be curious to hear what the next obstacle is when attempting to use it from Gradle. 😆

[petebankhead]

It works, thanks! After importing the version catalog as sciJava, I can now work around the profile problem with

dependencies {
    implementation(sciJava.bundles.fiji)
    {
        exclude(group = "org.jogamp.gluegen")
        exclude(group = "org.jogamp.jogl")
        exclude(group = "org.jogamp.joal")
        exclude(group = "org.bytedeco", module = "ffmpeg")
    }
    implementation(sciJava.org.jogamp.gluegen.gluegenRt)
    implementation(sciJava.org.jogamp.jogl.joglAll)
    implementation(sciJava.org.bytedeco.ffmpeg)
    // Can apply the JavaCPP Gradle plugin to avoid getting dependencies for all platforms here
    implementation("org.bytedeco:ffmpeg-platform:${sciJava.org.bytedeco.ffmpeg.get().version}")

    val classifier = getJogampClassifier()
    if (classifier != null) {
        implementation("org.jogamp.gluegen:gluegen-rt:${sciJava.org.jogamp.gluegen.gluegenRt.get().version}:natives-macosx-universal")
        implementation("org.jogamp.jogl:jogl-all:${sciJava.org.jogamp.jogl.joglAll.get().version}:natives-macosx-universal")
        implementation("org.jogamp.joal:joal:${sciJava.org.jogamp.joal.joal.get().version}:natives-macosx-universal")
    } else {
        logger.warn("Native libraries not found for jogamp")
    }
}


fun getJogampClassifier(): String? {
    if (Os.isFamily(Os.FAMILY_MAC)) {
        return "natives-macosx-universal"
    }
    if (Os.isFamily(Os.FAMILY_WINDOWS)) {
        return "natives-windows-amd64"
    }
    if (Os.isFamily(Os.FAMILY_UNIX)) {
        return if (Os.isArch("arm64")) {
            "natives-linux-aarch64"
        } else {
            "natives-linux-amd64"
        }
    }
    return null
}

[ctrueden]

@petebankhead Awesome!

One question: I see these lines amongst the above:

implementation("org.jogamp.gluegen:gluegen-rt:${sciJava.org.jogamp.gluegen.gluegenRt.get().version}:natives-macosx-universal")
implementation("org.jogamp.jogl:jogl-all:${sciJava.org.jogamp.jogl.joglAll.get().version}:natives-macosx-universal")
implementation("org.jogamp.joal:joal:${sciJava.org.jogamp.joal.joal.get().version}:natives-macosx-universal")

This is hardcoding for macOS... it should instead be:

implementation("org.jogamp.gluegen:gluegen-rt:${sciJava.org.jogamp.gluegen.gluegenRt.get().version}:$classifier")
implementation("org.jogamp.jogl:jogl-all:${sciJava.org.jogamp.jogl.joglAll.get().version}:$classifier")
implementation("org.jogamp.joal:joal:${sciJava.org.jogamp.joal.joal.get().version}:$classifier")

Right?

[petebankhead]

Oops, it should indeed, you can see what I was developing with....

[elect86]

I'd like to do some prototyping starting from a native library

Which one do you think would be the best, @ctrueden ?

[ctrueden]

@elect86 Sorry for the slow reply. I'm afraid I don't fully understand your question. Are you looking for a Java library in the SciJava component collection that depends on a JAR-wrapped native library using these native classifiers? If so, one high-level example is Fiji itself: https://github.com/fiji/fiji/blob/c82b94e540838b90071bc8dd67dac58f9c7b1fff/pom.xml#L861-L870

It seems to me that we could simply export all these native classifier properties also to the Gradle catalog as variables, no? Or is that not how catalogs work?

[elect86]

@elect86 Sorry for the slow reply. I'm afraid I don't fully understand your question. Are you looking for a Java library in the SciJava component collection that depends on a JAR-wrapped native library using these native classifiers? If so, one high-level example is Fiji itself: https://github.com/fiji/fiji/blob/c82b94e540838b90071bc8dd67dac58f9c7b1fff/pom.xml#L861-L870

It seems to me that we could simply export all these native classifier properties also to the Gradle catalog as variables, no? Or is that not how catalogs work?

Sorry for the late reply, kind of, I was looking for a project publishing directly native libraries

However, jogl could also make it, I'm thinking about re-publishing it internally on the scijava nexus with the proper corresponding Maven and Gradle tweaks

[elect86]

I just finished a prototype to re-publish the jogl libraries as variants

I'd like to use your case, @petebankhead, to test it out.. would you be available for that?

The idea is to have a Gradle plugin automatically setting the OS and Arch attributes based on the running system and then having Gradle fetching the right variant by itself

So that you'd just have to write

        implementation(sciJava.org.jogamp.gluegen.gluegenRt)
        implementation(scijava.org.jogamp.jogl.joglAll)
        implementation(scijava.org.jogamp.joal.joal)

@ctrueden we could publish them under new coordinates changing only the version, like 2.4.0-scijava or something like that.. what do you think?

[ctrueden]

Republishing JOGL under groupId org.scijava instead of org.jogamp makes sense to me. Note that the current version of JOGL is up to 2.5.0 now. When we forked Java 3D into SciJava, we also used a version suffix -scijava-1 like you suggest; there was later a -scijava-2 as well, so keeping a separate counter in that way could be useful.

That said: I still don't really understand why Maven classifiers aren't good enough? Does Gradle not support them well?

[elect86]

Maven classifiers are actually used

What I'm trying to do is writing some logic for the consumer that will automatically bind and add the corresponding native for the running system underneath at the runtime configuration (example)

[ctrueden]

OK, so if I understand correctly, the syntax will be something like:

dependencies {
    components {
        withModule<JoglRule>("org.jogamp.jogl:jogl-all")
    }
    implementation("org.jogamp.jogl:jogl-all:2.5.0")
}

?

Rather than republishing the JOGL artifacts, could this JoglRule simply be part of SciJava's Gradle logic?