This message was deleted.

Well, the module name autocompletion can only work if it already know the module. So for it to work you have to already have the dependency known to IntelliJ, by first adding it as dependency and then syncing. Then you could autocomplete the module name in IntelliJ. If the new dependency is not yet known, of course there is no autocompletion in the module info, as you only add the dependency to the project by adding the module info entry and then syncing.

yeah, I kind of thought so 😉 seems like a great idea for gradle to have in core, or convince intellij to add autocompletion for module info just from version catalogs

I don't think holding that "against" the approach is a fair argument. You also don't have code completion in the build files when you add dependencies. Apart from that, I think sometimes IDEA might suggest modules that re not on the path but used elsewhere in the project already. But I am not 100% sure. Anyway, everything else works perfectly in IDEA as with any Gradle project. I am in touch with projects using this in active development and there have been no issues I know of.

it's a good in theory... although, (and I'm confident it says it has a solution), what happens if people start actually using module-info in public libraries, actually I'm kind of curious how this can even work in some cases. Foolishly for example spring boot (core) doesn't have core. The exported automatic module can't match the name given in the version catalog. Now this makes me think it's always manipulating these jars, that doesn't sound great. Personally not going to use this one. It's a cool idea in theory, but I think in practice...

I cannot follow.

java-module-dependencies

as far as I got it does not manipulate any JARs and what other projects publish is irrelevant. It just translates the entries in

module-info.java

to dependency declarations so that you do not have to declare it twice. The final outcome is exactly the same.

but the entries in module-info.java have to be correct, they aren't arbitrary. JPMS only works if the jar provides a module info or automatic module

Yes of course

The names (coordinates) in the Maven repository and the module names do not have to match. They often don't. The plugin maintains a list of mappings for the libraries on Maven Central for this: https://github.com/gradlex-org/java-module-dependencies/tree/main/src/main/resources/org/gradlex/javamodule/dependencies And you can add your own mappings: https://github.com/gradlex-org/java-module-dependencies?tab=readme-ov-file#add-module-name-mapping-information-if-needed

which would be pointless... (generally). Either way, I think I'm just going to pass on this one. I like my auto completion too much

How did you collect "the libraries on Maven Central that are modules" @Jendrik Johannes?

But I also think it all only really makes sense if you go "full module". Which means: • You only use 3rd party libraries that have already module-info.class files • Or you patch the Jars that do not have them. For this you can use our other extra-module-info plugin, which can do a lot of things automatically now. For example computing the requires for the module-info based on the metadata. Then you can also use the jlink/jpackage tooling afterwards without hacking around the fact that some Jars are not modules. I am doing a lot of experimentation in this area at the moment and will probably publish more content on this soon. If you use these things cleanly and consistently, you can get a really neat setup with almost empty build files. So everything about your software structure is in Java directly. And Gradle moves more into the background.

Maybe we need a repository that auto-patch's modules that don't support JPMS