@timtebeek happy to pick this up also, please assign to me if that's okay!

Sure yes thanks, much appreciated! I'm thinking it might be best as a separate recipe, such that we don't have to update all downstream usage of AddDependency if an option were too be added there.

My initial thoughts were that it would be a new optional parameter to the AddDependency recipe, since when platform is added it's essentially just an extra layer between the configuration level (e.g. implementation) and the dependency coordinates as I understand it. Since it's an optional parameter it shouldn't break the existing contract and require other recipes to be updated (please correct me if I'm wrong).

If you feel a separate recipe is still better then happy to do so 😄

Another thought, maybe they can just share the visitor, and create a separate recipe like AddPlatformDependency.

So Maven opted for AddManagedDependency which allows adding a BOM as an import. I'd envision something almost akin to that for Gradle rather than adding an option to AddDependency itself. Almost all of the adding logic is already in the externalized visitor (AddDependencyVisitor which should be fine to add the extra parameters to), so there shouldn't be much that is needed for a top-level recipe. Maybe AddPlatformDependency with an option to choose between platform vs enforcedPlatform?

I think indeed an explicit AddPlatformDependency would be best.

When changing AddDependency we'd have to update any downstream usage explicit usage, like this example here, or would have to add backwards compatible constructors. Neither is very appealing given the long delay we'd see in adoption downstream.

Sharing code with the visitor as described above is of course possible and preferred here. Thanks both!

Sure, thanks for the help both! Will take a look at this.

Example was helpful too @timtebeek , I was originally just thinking about use within a declarative recipe style but didn't consider the constructor use like you have shown!

No problem at all, and thanks for getting clarity before jumping into an implementation, as it's a lot easier to steer now as opposed to when a lot have changes have gone in. :) Look forward to the PR!