This message was deleted.

Same as a normal dependency, but you need to consume it with

platform

It should be great there is a

[bom]

table so you can consume them without the

platform

function

hmm, how would you specify the platform in the version catalog, though?

as Javi said.

same as a normal dependency

[libs]
spring-boot-dependencies = { module = "org.springframework.boot:spring-boot-dependencies", version.ref = "spring-boot-dependencies" }

but you need to consume it with

platform

dependencies {
    api(platform(libs.spring.boot.dependencies))
}

(I don't use Spring so I don't know if this is actually the right dep)

hmm, how would I specify that in the version catalog? Would I have to go straight to toml? (I’m doing it with io.kotestkotest bom5.3.1 for now as a test)

I don't understand your issue. do the same thing to move your BOM dependency into your version catalog as you would any other dependency, regardless of whether the version catalog is defined via TOML or programmatically. the only difference between it and a normal dependency is at the consumer, which should be exactly the same difference as you have now.

If I have:

library("testbom", "io.kotest:kotest-bom:5.3.1")

in the

catalog { versionCatalog { … } }

block, and I publish it, the downstream consumer can have:

dependencies {
    testImplementation(platform(libs.testbom))

… but the dependencies don’t show up in the project. There is no

.dependencies

completion (

libs.testbom.dependencies

doesn’t work, nor does it work on

platform()

).

testbom

does complete, the

toml

has the library; if I set up a bundle that includes that library, it resolves, too, but the build fails because it can’t convert

platform(libs.bundles.testbundle)

to an object of type

Dependency

, nor do I see a completion that leads there from the bundle or from the call to

platform()

.

I'm not quite sure what you're trying to accomplish but... you can't "unbundle" a BOM/platform

if you add a

bom

to a configuration, any dependency in that configuration added by you, even with a different version, would be overridden with the version from the

bom

so you have to add the bom to the catalog, and all dependencies you need too, as you are going to get the version from the catalog automatically, you don't need to add the version to each one, so you can

[libraries]
foo-bom = { module = "org.example:foo:bom", version = "1.0.0" }
foo-dep = { module = "org.example:foo:dep" }

dependencies {
    implementation(platform(libs.foo.bom)
    implementation(libs.foo.dep)
}

@Javi is that not doable from the DSL?

it is the same with the Kotlin DSL

Okay. That’s what I think I’m missing, because I don’t see how.

move those two lines from toml to the dsl, that’s it

.. but if I’m doing that (that’s what I was doing in the first place) what’s the point of using the bom? Wouldn’t I be just as well off using a bundle?

bom ensure the dependencies are using specific versions for each dependency that are compatible among them

right, so… why shouldn’t there be a mechanism by which I say “Hey, there’s a bom for kotest, as an example: I would like to include the dependency X from that bom, thanks” without doing the manual inclusion?

I don’t know, you can create an issue for that

Worth noting: this does work: I include the bom, I included a module FROM the bom with

.withoutVersion()

, include the bom with platform, and include the library by name, and I get the dependency. But that means I am redeclaring the dependencies from the bom, just without version. If the bom version changes, I get to go through and add whatever the new version of the bom includes

you only need to change the bom version

so I could theoretically include the bom, include the libs, create a bundle MATCHING the bom’s dependency list (from “the libs”) and it gets the versions from the bom

you don’t need to apply a lib with any version, all without versions except the bom

@Javi Yeah, I know

a BOM was not intended to represent a bundle of libraries to import all at once

But I still get to recreate the structure of the external bom

correct. that's not available regardless of whether you are using version catalogs or not.

if a bom

external-bom:1.0

has libs

a:1.0

,

b:1.0

,

c:1.0

,

d:1.0

I get to declare all of a,b,c,d manually (and get the versions from the bom); if external-bom:1.1 comes out and adds

e

, I get to manually redeclare e except without the version

there is no codegen of accessors for bom internal dependencies, indeed, when you are applying it it is too late to codegen the accessors

only if you need to use

e

I can work with this

it is not the expected use case for a BOM that you import every library it mentions

I think he want something like,

libs.kotest.bom.declaredDependencies.assertions

sure, or

dependencies

like was referred to earlier, but eh

honestly, it might be possible to do a Gradle transform from a subset of POM syntax to a version catalog, although you'd have to register it very early (in

settings

)

but that would mean for gradle to detect all bom and codegen those properties even in modules in which the bom is not applied

but it doesn't feel like something common enough to be worthwhile

My main thing is needing to know what I need to do, which is not obvious to me from docs

I think the docs don't necessarily do a good job of delimiting what is part of Gradle's expectations of the Java ecosystem's conventions, what is Gradle's own conventions, and what is non-conventional but possible

Sure. Like I said, now that I understand better, the docs make more sense. The details are there, just not in a form that communicated effectively with me, and this is the first forum where anyone else has been able to provide any insight.

hmm. my personal complaint about the docs is that I often find that Google is more useful as an index than the docs' own table of contents, since the locations of some information is not where you'd expect due to history or other factors

Sure. It’s always a work in progress.

in this specific case, there are real full examples of where we ended up in many other projects, but perhaps not in Gradle itself. which is still a failing of the docs, but one I hadn't noticed before

AFAIK there is an example of when you need to use a Catalog or when to use a BOM, but I think more than a doubt among them, it is more a question about an expectation to improve the tool itself by providing those accessors

I don't think it's generally appropriate to generate accessors for all libraries in a BOM

I don’t think it’s necessary but it’d be useful. My biggest problem is that when I was trying to figure out what the path forward was to be, the docs were giving me the IKEA treatment: “here are the things you can use.” What I needed was “here’s how you put them together cohesively” instead of seeing the parts in specific.

to clarify, I do agree this is a fairly common case - this combination of importing versions from a BOM and also providing version-less libs in the catalog - and I'm sure I've seen it in dozens of public projects on GitHub

I’m going to write something up, like I said, because it’s not good that I didn’t find it trivially; I’m sure it’s out there, but if you can’t find it, that means that there’s a gap somewhere. I’m unlikely to actually contribute new knowledge, but maybe I’ll help fill an SEO gap.

that's not necessarily something that Google can guide you to so it not being in the docs is a gap

@ephemient… but it IS. That’s the SEO gap. I’m sure you’re right, I’m sure projects DO fulfill this, but I was searching and not finding.

I think we're mostly in agreement here?

Probably.

if you write and publish a blog, yes that helps close the Google SEO gap. several members of this community have actively done that in the past

Hell, I’ll put it on TheServerSide 🙂

beyond that, the best way to improve the docs is to contribute to them, and probably second best is to file issues in the issue tracker

most of what I put there is about the industry and not actually programming, this will be a change-up 🙂