Migrate add Develocity recipes to handle the new develocity configurations

[shanman190]

What's changed?

• When adding Develocity to a new Gradle project make sure to use the new Develocity configuration names as of 3.17.x
• When adding Develocity to a new Maven project make sure to use the new Develocity configuration names as of 3.17.x
• Migrate an existing Gradle project configured with Develocity or Gradle Enterprise < 3.17 to use the new configurations for 3.17.x and newer (moved to Add Gradle Enterprise to Develocity 3.17+ migration recipe for Gradle #4320)
• Migrate an existing Maven project configured with Develocity or Gradle Enterprise < 3.17 to use the new configurations for 3.17.x and newer

What's your motivation?

Gradle Enterprise was renamed to Develocity and as such the Gradle plugin has been equally renamed including with a Maven POM relocation. Additionally changes to the configuration names have been introduced as part of the product rename and must be taken by end users.

Anything in particular you'd like reviewers to focus on?

https://docs.gradle.com/enterprise/gradle-plugin/legacy/#develocity_migration
https://docs.gradle.com/enterprise/maven-extension/legacy/#develocity_migration

Anyone you would like to review specifically?

Not in particular.

Have you considered any alternatives or workarounds?

Do the migration manually

Any additional context

• Migrate from Gradle Enterprise Maven extension to Develocity plugin #4134
• Migrate from Gradle Enterprise gradle plugin to Develocity plugin  #4135

Checklist

• I've added unit tests to cover both positive and negative cases
• I've read and applied the recipe conventions and best practices
• I've used the IntelliJ IDEA auto-formatter on affected files

[timtebeek]

Great start! Let me know if you'd like a review & potential merge already, or whether you'd like to continue on this branch for a little while longer. The draft status had me thinking the latter, but the tasks outlined at the top might better fit into separate PRs, so then it's slightly unclear what the exact status of this PR is.

[shanman190]

@timtebeek, will do! I was thinking about it a little bit and I think a good split may be on finishing up the updates required for both "add to new project", then split the migrate off to another PR. It could possibly be better to even split the migrates up into two separate PRs for each of Gradle and Maven, but I'm not sure yet.

I just wanted to get something out there to kick off some discussion, if needed, and elevate awareness that this is coming and will soon be required to have been completed by Develocity users.

[timtebeek]

Both of those splits sound good to me; let's see if @jean-andre-gauthier has anything to add to this already, and continue down this path.

[shanman190]

@timtebeek, I'm marking this ready for review as now the add recipes will correctly use the non-deprecated Develocity configurations.

I'm going to start on the migration recipe for Gradle in a new PR, so keep an eye out for that coming shortly.

[timtebeek]

Thanks a lot! One thought that crossed my mind is when we would phase out the "Add Gradle enterprise" parts of these recipes. Is there a good reason to keep those around? And if so; should that be an option on these existing recipes, or would a rebranded copy of these recipes make sense, such that it's easier to remove the old recipes down the line?

[shanman190]

@timtebeek, that is a very valid question and I'm not sure on the answer there. From a Develocity standpoint, historically any older plugin version worked with a new server version, but the Gradle version would sometimes determine which variation you'd use. A new plugin version will often have a minimum required server version otherwise it will log an error stating that it is incompatible with the current server version.

Maybe the folks over at Gradle can provide some more guidance on their expectations? I had considered dropping the old support, but I didn't have the answer that you're looking for either.

https://docs.gradle.com/develocity/compatibility/#gradle_build_tool_compatibility
https://docs.gradle.com/develocity/compatibility/#gradle_build_tool_compatibility

[erichaagdev]

I suggest leaving the Add Gradle Enterprise recipe for now. @shanman190 is right – Develocity installations have a maximum supported plugin version and it's not uncommon for some organizations to be running older Develocity versions. In those cases, they will still need to apply the Gradle Enterprise plugin.

As a point of reference, the Develocity plugin is only compatible with Develocity 2024.1+ which was only released April 2, 2024. It will take some time before the majority of users are on 2024.1+.

[shanman190]

@erichaagdev, awesome! Thanks for the insight!

The current AddDevelocityGradlePlugin and AddDevelocityMavenExtension will each apply their respective Gradle Enterprise configurations when the chosen plugin version is < 3.17, then use the Develocity configuration for 3.17+.

[erichaagdev]

Ah, thanks for the clarification. If they do the same thing then I don't see a reason to keep the Gradle Enterprise one.