This doesn't sound like something that should be part of a plugin for JavaCPP. Wouldn't that be more appropriate in a more generic plugin for jlink like https://github.com/moditect/moditect-gradle-plugin ?

The platforms property replaces the javacppPlatforms extension property, but configuring the extra property is still supported for backward compatibility. Directly using the platforms property in a javacpp DSL block looks just a bit better.

The problem with properties from custom classes like that is that I haven't found a way to let users set them from the command line. Am I missing something?

From what I understand of how Gradle works, when inferModulePath isn't disabled, it should already be putting everything the module path, by default: https://docs.gradle.org/current/userguide/java_library_plugin.html

Why isn't this happening?

Ah, it looks like the badass plugin does its own inferencing instead of just using the module path from Gradle, see beryx/badass-jlink-plugin#198. I don't see the point of finding only the native modules related to JavaCPP when users probably just want to add all dependencies that they list anyway. Could you elaborate on the use case as to why this needs to be specific to JavaCPP modules instead of just taking everything from the module path?

The problem with properties from custom classes like that is that I haven't found a way to let users set them from the command line. Am I missing something?

I haven't found either. But the platforms extension property is initialized with extra property javacppPlaform, if it exists, so -PjavacppPlaform=... still works.

From what I understand of how Gradle works, when inferModulePath isn't disabled, it should already be putting everything the module path, by default: https://docs.gradle.org/current/userguide/java_library_plugin.html

Why isn't this happening?

The module path does contain everything, it even contain too much (see below). The problem adressed by this PR is to
popupate the readable module graph, not the module path.

Could you elaborate on the use case as to why this needs to be specific to JavaCPP modules instead of just taking everything from the module path?

"Taking everything from the module path" is covered by the --add-modules special value ALL-MODULE-PATH.
This works, if the module path doesn't not contain more that what is sufficient.
The problem with the Badass plugin is that it systematically adds $JAVA_HOME/jmods to the module path, thus the whole jdk ends up in the image if we use --add-modules ALL-MODULE-PATH.
This might be considered as a bug. Since Java 10 we have this feature and the Badass and other plugins should probably rely on this feature and not add $JAVA_HOME/jmods. I'll raise an issue and see what the author thinks about it.
Another possible problem is with automatic modules, like the one from JavaFX, that must be in the dependencies, but not in the jlink module path. However it looks like the Badass plugin filters them out. If we use the Gradle module path computed by inferModulePath, it would contain the automatic modules.

I agree that this PR doesn't bring a very satisfactory solution for people needing to link with Gradle. For instance, the way it selects the modules to add : from the runtime paths and looking for "system.arch" in their name, is not rigorous.
The ideal solution for me would be to pre-extract the native libraries in the image runtime instead of adding the native jars.

I agree that this PR doesn't bring a very satisfactory solution for people needing to link with Gradle. For instance, the way it selects the modules to add : from the runtime paths and looking for "system.arch" in their name, is not rigorous. The ideal solution for me would be to pre-extract the native libraries in the image runtime instead of adding the native jars.

Right, so, like I tried to explain before, Android is also too dumb to support native libraries bundled in JAR files, but we can easily compensate for that by extracting the libraries manually using Gradle, and spoon-feeding the extracted directory to its plugin. I've added documentation for that at the bottom of the README.md file, it's literally just 10 lines of code! But you know 10 lines of code is way too much code for the Android team to add to their plugin. What they want us to do is publish AAR files instead of JAR files. And now OpenJDK wants us to publish native modules in JMOD files instead of JAR files, so it's like what the hell is this crap? It triples the size of binaries uploaded to Maven Central, and it triples the time we have to maintain them. I'm not going to play that game! Why not just support JAR files, you know? They work just fine, OSGi has been supporting native libraries in JAR files for like forever, and it works just perfectly fine thank you! There's absolutely no reason to deal with this idiocy. Since neither Google nor Oracle is interested in making Java a sane platform when it comes to native binaries, we need to figure out something on our own. For starters, I'm sure we can come up with a hack very similar to the one for Android, but for jlink, so please do give it a try. If you are absolutely sure there is no way to deal with this in a sane way, then let's continue complaining at OpenJDK. It's their problem, also because Android depends OpenJDK. Maybe they will listen, eventually, but the chances of this happening are greater if we are able to show them that JAR files are sufficient and that we don't need JMOD files.

/cc @jjh-aicas @johanvos @mikehearn @timothyjward

In the meantime, what about generalizing your Android workaround and add some lines of code to this Gradle plugin that add the option of pre-extracting the native jars into the jlink images ?

If you know a way to make this work, let's have a look at that, yes. That's what I said could help us convince people at OpenJDK to start doing the right thing.

Here it is: #21