[Help]: Gradle plugin does not download platform-specific artifacts from maven repository

[rkechols]

I'm trying to use the gradle javacpp platform plugin to incorporate platform-specific artifacts into a project, and it seems that the plugin is not downloading the platform-specific artifacts at all to be incorporated into the build.

See also atsushieno/ktmidi#98

To focus in on the problem (as highlighted in the issue linked above), platform-specific artifacts are published on maven (visible here) but they are not pulled into the build as expected.

I've made a simple example project to illustrate the issue:
https://github.com/rkechols/ktmidi-demo

Reproducing the issue should be as simple as cloning that repository, and running ./gradlew run, which gives output like this:

$ ./gradlew run                                                                                                                                                                                                                                                                                                     
Type-safe project accessors is an incubating feature.                                                                                                                                                                                                                                                               

> Configure project :composeApp
platform = windows-x86_64

> Task :composeApp:run
osName: windows 11
Warning: Version of dev.atsushieno:libremidi_javacpp could not be found.
Failed to use LibreMidiAccess: java.lang.UnsatisfiedLinkError: no jnilibremidi in java.library.path: C:\Program Files\Eclipse Adoptium\jdk-21.0.6.7-hotspot\bin;C:\WINDOWS\Sun\Java\bin;<truncated>;.
Warning: Version of dev.atsushieno:rtmidi_javacpp could not be found.
Failed to use RtMidiAccess: java.lang.UnsatisfiedLinkError: no jnirtmidi in java.library.path: C:\Program Files\Eclipse Adoptium\jdk-21.0.6.7-hotspot\bin;C:\WINDOWS\Sun\Java\bin;<truncated>;.
Using JvmMidiAccess as last resort
# of input devices via jvm: 1

Deprecated Gradle features were used in this build, making it incompatible with Gradle 9.0.

You can use '--warning-mode all' to show the individual deprecation warnings and determine if they come from your own scripts or plugins.

For more on this, please refer to https://docs.gradle.org/8.9/userguide/command_line_interface.html#sec:command_line_warnings in the Gradle documentation.

BUILD SUCCESSFUL in 3s
11 actionable tasks: 1 executed, 10 up-to-date

My primary platform for testing is Windows 11 x86_64, but I also have Linux and macOS systems available to test on that experience the same issue.

I'm not sure whether this is actually a problem with gradle-javacpp, a problem with the artifacts/libraries from dev.atsushieno I'm trying to use, or a problem with my project setup, but I'd much appreciate help narrowing down the problem from someone well-versed with gradle-javacpp.

[saudet]

I don't see any platform artifacts.

[rkechols]

I don't see any platform artifacts.

At the link posted above (https://repo1.maven.org/maven2/dev/atsushieno/libremidi-javacpp/0.1.4/) I see these platform-specific artifacts (among other artifacts):

libremidi-javacpp-0.1.4-linux-x86_64.jar          2025-02-05 15:13    187997      
libremidi-javacpp-0.1.4-macosx-arm64.jar          2025-02-05 15:13     87178      
libremidi-javacpp-0.1.4-macosx-x86_64.jar         2025-02-05 15:13     94403      
libremidi-javacpp-0.1.4-windows-x86_64.jar        2025-02-05 15:13    754981      

Are those somehow not visible to you? Or do they somehow not "count"?

I sincerely apologize if my naiveté bothers you; your patience would be much appreciated as I learn a new tool.

[saudet]

When I talk about platform artifacts, I mean artifacts with the string "platform" in their names. I don't see any files with "platform" in their names.

[atsushieno]

Let me help you understand how Maven Central locates Maven artifacts so that you can easily guess where you can find "platform" artifacts. It would help you understand how your own Maven artifacts for javacpp-presets are located as well.

When you see some Maven artifacts URL such as ^ (https://repo1.maven.org/maven2/dev/atsushieno/libremidi-javacpp/0.1.4/), it means that the artifact is published at https://repo1.maven.org/maven2/ (for other artifacts, there can be other repository URLs).

When gradle-javacpp publishes its target artifacts (one for the primary module and another for -platform module) they are published to the same destination.

From the URL above, you can see some path parts /dev/atsushieno/libremidi-javacpp/0.1.4/ . This means that the package identifier is dev.atsushieno:libremidi-javacpp:0.1.4 in short notation.

If you think "there should be -platform artifact", then you can guess that there should be the corresponding package located at /dev/atsushieno/libremidi-javacpp-platform/0.1.4/. Let's see if it is correct. If you open the URL above, the page should look like this:

Click ".." part, and then you are navigated to the parent directory:

Now you'll see all packages I have published in the past. Scroll down to l and find libremidi-javacpp:

You can find there is libremidi-javacpp-platform ! Enter the directory, and pick up the corresponding version (it is versioned as well). Now you can find the package contents here:

https://repo1.maven.org/maven2/dev/atsushieno/libremidi-javacpp-platform/0.1.4/

The same locating principles apply to javacpp-presets e.g. flycapture:

• https://repo1.maven.org/maven2/org/bytedeco/flycapture/2.13.3.31-1.5.9/
• https://repo1.maven.org/maven2/org/bytedeco/flycapture-platform/2.13.3.31-1.5.9/

I hope this helps!

[saudet]

Thanks @atsushieno ! So the platform artifacts are there, but they don't contain any dependencies on the platform-specific artifacts (the linux, mac, windows, etc ones):
https://repo1.maven.org/maven2/dev/atsushieno/libremidi-javacpp-platform/0.1.5/
You'll need to add the dependencies in there.

[atsushieno]

but they don't contain any dependencies on the platform-specific artifacts (the linux, mac, windows, etc ones)

It is actually what I did not understand when I published my version 0.1.4 that removed them all, and I brought back (or "tried to", I'd say) at 0.1.5: atsushieno/libremidi-javacpp@f50ebff

It is based on what samples/zlib/build.gradle does: https://github.com/bytedeco/gradle-javacpp/blob/e4de6606200654777ea9f6af30df10bf835e713d/samples/zlib/build.gradle#L17C1-L31C2

If it does not generate the dependencies (like how flycapture-platform has), then I assume gradle-javacpp is failing to deal with these items. Or some other parts in my build.gradle is bringing in conflicts, overwrites etc. But as far as I read gradle-javacpp sources I don't see any code that generates this dependencies section. Any hints are appreciated.

[saudet]

The content of the platform artifact can be generated with xmlAction like this:
https://github.com/bytedeco/gradle-javacpp/blob/master/samples/zlib/build.gradle#L126

[atsushieno]

Yes, I follow that. And that (BuildExtension.xmlAction()) seems to only generate <profiles>, without <dependencies> etc. (full pom file here):

...

Compared to flycapture-platform POM, gradle-javacpp outcome misses:

• dependencies like this:

<dependency>
<groupId>${project.groupId}</groupId>
<artifactId>${javacpp.moduleId}</artifactId>
<version>${project.version}</version>
<classifier>${javacpp.platform.linux-x86}</classifier>
</dependency>

• manifest entries like this:

<configuration>
<archive>
<manifestEntries>
<Class-Path>
${javacpp.moduleId}.jar ${javacpp.moduleId}-linux-x86.jar ${javacpp.moduleId}-linux-x86_64.jar ${javacpp.moduleId}-linux-armhf.jar ${javacpp.moduleId}-linux-arm64.jar ${javacpp.moduleId}-windows-x86.jar ${javacpp.moduleId}-windows-x86_64.jar
</Class-Path>
</manifestEntries>
</archive>
</configuration>

• moditect module definition like this:

<configuration>
<modules>
<module>
<file>
${project.build.directory}/${project.artifactId}.jar
</file>
<moduleInfoSource>
module org.bytedeco.${javacpp.moduleId}.platform { requires static org.bytedeco.${javacpp.moduleId}.linux.x86; requires static org.bytedeco.${javacpp.moduleId}.linux.x86_64; requires static org.bytedeco.${javacpp.moduleId}.linux.armhf; requires static org.bytedeco.${javacpp.moduleId}.linux.arm64; requires static org.bytedeco.${javacpp.moduleId}.windows.x86; requires static org.bytedeco.${javacpp.moduleId}.windows.x86_64; }
</moduleInfoSource>
</module>
</modules>
</configuration>

On the other hand, flycapure (non-platform) package does not seem to have .module file unlike what gradle-javacpp generated for libremidi-javacpp (again, non-platform). I guess that's what moditect generates at app-build time and not needed for gradle-javacpp build, yet this .module file needs to be generated at -platform side...?

[saudet]

What happens if you build https://github.com/bytedeco/gradle-javacpp/blob/master/samples/zlib/ ?

[atsushieno]

This build failure:

FAILURE: Build failed with an exception.

* What went wrong:
A problem was found with the configuration of task ':javacppPomProperties' (type 'WriteProperties').
  - Gradle detected a problem with the following location: '/Users/atsushi/sources/gradle-javacpp/samples/zlib/build/resources/main/META-INF/maven/org.bytedeco/zlib/pom.properties'.
    
    Reason: Task ':javacppBuildCommand' uses this output of task ':javacppPomProperties' without declaring an explicit or implicit dependency. This can lead to incorrect results being produced, depending on what order the tasks are executed.
    
    Possible solutions:
      1. Declare task ':javacppPomProperties' as an input of ':javacppBuildCommand'.
      2. Declare an explicit dependency on ':javacppPomProperties' from ':javacppBuildCommand' using Task#dependsOn.
      3. Declare an explicit dependency on ':javacppPomProperties' from ':javacppBuildCommand' using Task#mustRunAfter.
    
    For more information, please refer to https://docs.gradle.org/8.10/userguide/validation_problems.html#implicit_dependency in the Gradle documentation.

There has been a lot of changes in Gradle that forces us to describe explicit dependencies. It is not the only one, and I cannot figure out how to fix this:

    Reason: Task ':javacppBuildCommand' uses this output of task ':generatePomFileForMavenJavacppPlatformPublication' without declaring an explicit or implicit dependency. This can lead to incorrect results being produced, depending on what order the tasks are executed.
    
    Possible solutions:
      1. Declare task ':generatePomFileForMavenJavacppPlatformPublication' as an input of ':javacppBuildCommand'.
      2. Declare an explicit dependency on ':generatePomFileForMavenJavacppPlatformPublication' from ':javacppBuildCommand' using Task#dependsOn.
      3. Declare an explicit dependency on ':generatePomFileForMavenJavacppPlatformPublication' from ':javacppBuildCommand' using Task#mustRunAfter.
    

Gradle gives wrong error message as usual and tasks.named("javacppBuildCommand").configure { dependsOn("generatePomFileForMavenJavaPublication") } doesn't fix the issue.

[atsushieno]

Okay I seem to have disposed of that buggy build failure message with this: tasks.named("javacppBuildCommand").configure { dependsOn(tasks.withType(GenerateMavenPom)) }

publishToMavenLocal gives me this output at ~/.m2/repository/org/bytedeco/zlib-platform/1.3.1-1.5.10/zlib-platform-1.3.1-1.5.10.pom: https://gist.github.com/atsushieno/9e72a92953048a068398ca7529365109