This message was deleted.

Very nice @Jendrik Johannes!

Nice! Have you considered supporting an additional property in the version catalog toml for binding module name to GAV rather than

moduleNameToGA

in the gradle build file? And avoiding having a naming convention for the version so it can be reused across dependencies? I'm imagining:

[versions]
commonslang = "3.12.0"
jackson = "2.12.5"

[libraries]
commons-lang3 = { module = "org.apache.commons:commons-lang3", version.ref = "commonslang", jpms.name = "org.apache.commons.lang3" }
jackson-core = {  module = "com.fasterxml.jackson.core:jackson-core", version.ref = "jackson", jpms.name = "com.fasterxml.jackson.core" }
jackson-databind = {  module = "com.fasterxml.jackson.jackson-databind", version.ref = "jackson", jpms.name = "com.fasterxml.jackson.databind" }

Don't know how easy it is to extend the TOML spec in this way, but it might be a way to keep the metadata together without relying on

modules.properties

/

unique_modules.properties

, and still remove version duplication.

I don’t think the Catalog is designed for such extensibility. The integration right now also does not feel really good to me. I tried that, because we need a place for Versions and the Catalog has a [versions] section. That sound like a fit in theory. But there are issues. Like that you can’t refer to a version that you have already declared. And you can’t use the exact names either because

.

is not allowed. Right now, I think the Catalog is not a good fit for Java Module projects as you don’t use much of its features anyway. Right now defining versions in constraints using the

gav("module.name", "version")

notation feels like the better solution to me. For the mappings: I want the plugin to deliver them so that you don’t need to define them at all. Because they are (with minor exceptions) unique and universal. The idea is really that in the ideal case you never have to deal with coordinates anywhere in the build. And if, only for a few mapping adjustments you do deep down in your convention plugins (and rarely touch). Why do you want to define mappings yourself?

I'm suspicious of things that depend on bundled metadata - it gets stale so easily if no-one's being paid to look after it for the long term. And I feel a bit odd about that uncertainty of "does the tool know about this lib? No, have to tell it..." - I quite like the simplicity of just telling it about every lib. I'm also hopeful that the toml is sufficiently standardised and easy to parse that it will rapidly become something tools like dependabot can reliably work with.

Yes ok that’s a bit different perspective on it. You already can define your own mappings. Just not in the Catalog. Whether that should be made more extensible is a topic on its own. I am pretty sure it is not possible right now. But I am happy to talk about extending the DSL the plugin offers if there are good arguments. e.g.: • Deactivating the bundled mappings completely (that sounds useful and shouldn’t be too hard) • Offer an API to directly define a mapping with a version (which would be what you proposed above I think, just not in the catalog but in the normal DSL) Feel free to open an issue for these.