This message was deleted.

I think because you use the platform on

implementation

its constraints do not leak downstream and so in the consumer you miss the version. Try using the

platform

on

api

instead.

How would the latter work? Suppose my platform is only used internally and is never meant to be published anywhere (ie. it doesn't even apply

publishing

).

That's the point. Currently your dependency does not have a version and that is also published like that. There is a setting to publish resolved versions instead, so the version coming from the platform would be published for the dependency directly

So I would need to apply a publishing plugin even if I do not intend to ever publish the platform to a remote repository, just for the sake of being able to generate a platform with versions?

No, you don't listen. I did not say to publish the platform. You are publishing your plugin. You are currently publishing declared version which is no version. And I said you should publish resolved versions instead, which is a setting

I did add this to `plugin`:

publishing {
  publications.withType<MavenPublication>().configureEach {
    versionMapping {
      allVariants {
        fromResolutionResult()
      }
    }
  }
}

I'm not sure where else I could be setting this, but removing the declared version from the version catalog in an effort to rely on the platform is still causing

smoke

to fail to be configured when it includes

plugin

and tries to apply the plugin produced therein.

Hm, can you maybe knit an MCVE demonstrating your issue?

The more I think about it, the more I think it is self-inflicted. I was following the example here: https://github.com/jjohannes/gradle-demos/tree/main/internal-platform and there is reason to believe that one of the platforms that I pull in in the internal platform is meant to be exposed as

apiElements

. I'm still having to rationalize the logic in my head.