Hello! For some obscure reason, Gradle is not using my .module file by default but the pom instead: https://repo1.maven.org/maven2/io/mvnpm/esbuild-java/2.0.0-beta-2/ If I set this it works:

mavenCentral()  {
        metadataSources {
            gradleMetadata()
            mavenPom()
        }
    }

the weird thing is that for other repos such as guava or junit, it does look for the .module file in central even without this conf. I might be missing something..

2025-11-05T20:17:32.455+0100 [DEBUG] [org.gradle.internal.operations.DefaultBuildOperationRunner] Completing Build operation 'Metadata of <https://repo.maven.apache.org/maven2/io/mvnpm/esbuild-java-native-deps/2.0.0-beta-2/esbuild-java-native-deps-2.0.0-beta-2.pom>'
2025-11-05T20:17:32.456+0100 [DEBUG] [org.gradle.internal.operations.DefaultBuildOperationRunner] Build operation 'Metadata of <https://repo.maven.apache.org/maven2/io/mvnpm/esbuild-java-native-deps/2.0.0-beta-2/esbuild-java-native-deps-2.0.0-beta-2.pom>' completed

...

2025-11-05T20:17:32.308+0100 [DEBUG] [org.gradle.internal.operations.DefaultBuildOperationRunner] Completing Build operation 'Metadata of <https://repo.maven.apache.org/maven2/com/google/guava/guava/33.5.0-jre/guava-33.5.0-jre.module>'
2025-11-05T20:17:32.308+0100 [DEBUG] [org.gradle.internal.operations.DefaultBuildOperationRunner] Build operation 'Metadata of <https://repo.maven.apache.org/maven2/com/google/guava/guava/33.5.0-jre/guava-33.5.0-jre.module>' completed

Your POM doesn't contain the marker comment instructing Gradle to look for a module metadata file: https://docs.gradle.org/current/userguide/publishing_gradle_module_metadata.html#sub:interactions-other-build-tools

ahhh

Guava also generates them from Maven Fwiw: https://repo.maven.apache.org/maven2/com/google/guava/guava/33.5.0-jre/guava-33.5.0-jre.pom See the

<!--  do_not_remove: published-with-gradle-metadata  -->

line? When generated with Gradle, the POMs will also include a comment explaining why it's there; see e.g. on one of my projects: https://repo.maven.apache.org/maven2/net/ltgt/gradle/incap/incap/1.0.0/incap-1.0.0.pom

Awesome!!

We also have a Maven Plugin for that: https://github.com/gradlex-org/gradle-module-metadata-maven-plugin There are some notes on the marker topic in the Readme, that may be helpful: https://github.com/gradlex-org/gradle-module-metadata-maven-plugin?tab=readme-ov-file#using-the-plugin

Hey @Jendrik Johannes have a look at the module, it is a bit special: https://repo1.maven.org/maven2/io/mvnpm/esbuild-java-native-deps/2.0.0-beta-2/esbuild-java-native-deps-2.0.0-beta-2.module I am not sure I can generate it with the plugin?

Yes the plugin cannot do this right now. But it would be interesting features (maybe) to: 1. Specifically support adding native variants 2. Or support adding arbitrary additional variants with custom attributes and dependencies Probably (2), as for (1) you have several options. Specific dependencies (as you have). Or different Jars with classifier directly in the variants (e.g. as JavaFX has) etc. Open for suggestions and contributions if you are interested. But it's totally fine not to use the plugin if you have a working solution in your Maven build now.

I spent already quite some time figuring how to have a solution working both Maven/Gradle and with a nice user xp and I am finally there (just the need for the plugin on Gradle which is fine until better). So I'll keep it as it is for now. I think it's a good idea to evolve the plugin to work with this case, and I might contribute it after a small break on this part 🙂 Anyway thanks you very much and I'll also apply your suggested changes on the gradle plugin unless you want to add the PR directly. Cheers!

Anyway thanks you very much and I'll also apply your suggested changes on the gradle plugin unless you want to add the PR directly.

Please go ahead and do this yourself. I have enough PRs in enough projects laying around right now. 😄 Happy to review the changes though once you have done them.

ok that's very interesting! I am part of the the Quarkus team, you might know @Alexey Loubyansky, he is contributing a lot in the area of dependency management

Thanks for the context!

I think #C07GJEMUZDH is supposed to be the of new place for the recommended set of plugins so to speak. Semi-community maintained.

Yes definitely. Although there are two different aspects I see (both are not working well at the moment): 1. Have some kind of list where each plugin follows a certain "quality standard" in terms of how it behaves. E.g. does not break a performance feature such as config cache, is actively maintained (ideally not just by one person) so that if something breaks, the chance that it gets fixed, or that a fix I provide will be integrated, is high etc. I think @Oleg Nenashev is also conscious of this and there are ideas to improve this through https://community.gradle.org. E.g. having some automated test bed a plugin must pass. Or maybe having community owned orgs like GradleUp that follow certain standards so that they are "endorsed" by Gradle itself. If that is then well communicated, a user (new to this or not) can assess if a plugin is something they can use without too much concerns. These plugins can be anything from general purpose that is usable in custom Gradle build systems, to Java specific plugins, or Kotlin specific plugins, etc. Right now, there are no such easy to discover lists. If you go to the Plugin Portal for example, everything is the same and it is hard to get orientation on what you may use as a good extension for Gradle core in rather standard project setups. 2. What I was talking about above is the "Java core" ecosystem. Users who do Java. No Kotlin. No Android. No super fancy niche usages of Java. This topic is traditionally owned by Gradle core itself. But in practice it already changed. You rarely see a Java build without community plugins. And I think that is good. Community plugins can move more swiftly and can offer alternatives where required. While Gradle core somehow always has to support all cases at once and keep backward compatibly with the whole world. So when I look at a Java project today, for example, in my opinion every build should have at least

com.autonomousapps.dependency-analysis-gradle-plugin

and

org.gradlex.jvm-dependency-conflict-resolution

on top of Gradle core. And then there are some others depending on which features you need in your development and deployment process (e.g. do you use JPMS, do you want code analysis/formatting, do you want to publish to Maven Central etc.). But there is a limited list of these features that fits many many projects. If I am new to this and search for "how to build a Java project", I should find a Gradle setup which gives me a such good setup to start with. If both things existed, (2) should only contain plugins that are also contained in (1).

What Oleg is aware of is unfortunately irrelevant, as we lost him from Gradle some time ago :-(

Yeah I know that he is no longer in that role, but I am hoping he stays active (or becomes active again) in the community. Mentioned him, because I think he was the driving force behind community.gradle.org - I don't know if there are any further plans for that atm.

Will you document this somewhere for your users? I am interested to see both Gradle and Maven solution. Getting a good user experience should be the goal. And ideally one that is the same at some point no matter which "Native Jars" you use.

We will document it for Gradle yes as part of the https://github.com/quarkiverse/quarkus-web-bundler doc for Gradle usage (to add the plugin), In the case of Maven, it's using arch/os based profile activation which in the end is pretty similar to variants but don't require a plugin for the arch/os part. https://github.com/mvnpm/esbuild-java/blob/main/native-deps/pom.xml#L64-L83

He was the driving force behind

<http://community.gradle.org|community.gradle.org>

, yes. But I somehow doubt that he will do any more significant work on

*.<http://gradle.org|gradle.org>

and I think I've not seen him online here since he left.

I am here and I am still reading this workspace from time to time, but I cannot communicate much due to the reasons outside of my control, sorry. I am likely to be more present once my garden leave is over

My 2 cents: 1. I want Gradle to have a "strict" mode that crashes hard whenever a plugin is doing something illegal (non-lazy API, deprecated API, breaks configuration caching, etc...) 2. Ideally every ecosystem plugin is 3rd party. I think it made sense initially for Gradle to come up with "java" and "maven" plugins to kickstart things but the API surface that Gradle has to maintain is huge and I'd rather have other folks (Google, Jetbrain, Sonatype, Oracle?, etc..) maintain the plugins so that Gradle can focus on the build tools APIs (and do 1.)

I mean having used languages that have strict mode I would honestly say that it's usually not a great indicator of quality. Not meeting it is definitely an indicator of non-quality but...

Yes, there is a gazillion of small individual toggles. I want one big opinionated one.

Gradle wouldn't pass my big opinionated one . I mean it still doesn't pass the whole lazy thing

Yea, that's a concern

Anyways I don't disagree with your idea in general... But I don't know how I would tell you to get there.

Then we, as a community, don't have to curate lists of "good" plugins, good practices, etc... "Good" plugins would just display on their README that they are compatible with Gradle strict mode 🥇

I didn't think this is true. As Caleb said, just passing strict mode does not ensure goodness. And even if it did, there would be a need for a curated list, otherwise you have to click through all plugin's readmes to find good ones, and if there are similar ones you also need curation about what to use best in the opinion of the curator.

Maybe the list of plugins should just be reviewed by a panel of people giving some kind of certificate that needs to be renewed if there is a big change

Btw. a strict mode wouldn't be that easy or obvious. I don't disagree some strict mode would be nice, but it is highly questionable what should go on in there. To just name one example, lazy vs. eager API. If you create a new domain collection and exclusively handle it lazy, it will never be realized and then never be used. Even within Gradle code this happened at least once. So depending on situation, there eventually has to be at least one eager call somewhere to kick off the configured actions.

I agree it's hard. But it would also be very valuable to move the ecosystem

I agree it's hard. But it would also be very valuable to move the ecosystem

Sure, just saying that even for the "old stuff" there might still be important and valid use-case, so a plugin can be perfectly fine, following all best-practices, provide super service, and still would not be able to say "compatible with strict mode" if the strict mode would forbid all eager API.

the strict mode would forbid all eager API.

Probably it means the strict mode needs to be smarter than that. I.e. define "phases" when it's OK or not to call the eager APIs.

A relatively dumb strict-mode checker that just forbids certain APIs to be used could maybe be done relatively easy. Take the Gradle Public API classes, throw out all APIs that you want to forbid, try to compile against that stripped down API. 😄

I thought there was an issue already but didn't found one so I created https://github.com/gradle/gradle/issues/35590

You probably had https://github.com/gradle/gradle/issues/16344 in mind. Zac just tends to close good issues out of frustration. 😞

Ah yes, good find!

I understand the frustration too. But closing good issues is imho the wrong way to deal with it. If they are closed it is guaranteed that noone looks at them anymore. If they are open, there is at least a tiny chance it will be considered at some point.

Yea

yeah for example in Quarkus we have a lotery on open issues (to make sure we don't forget issues)

@Andy Damevin that sounds interesting 🙂 How does that work? A random issue gets assigned to someone every week?