Download Maven extensions instead of bundling them #476
Conversation
README.adoc
Outdated
| See <<Enable auto-injection>> for details. | ||
| The compatibility of the specified version with Develocity can be found https://docs.gradle.com/enterprise/compatibility/#maven_extension[here]. | ||
|
|
||
| For the optional Common Custom User Data Maven extension which is defined the same form, you can see the compatibility of the specified version with the Develocity Maven extension https://github.com/gradle/common-custom-user-data-maven-extension#version-compatibility[here]. | ||
|
|
There was a problem hiding this comment.
Shouldn't we put a warning note explaining that the injection will not work after upgrading referencing jenkins-infra/helpdesk#4263.
There was a problem hiding this comment.
I thought about adding it to the release notes only.
Do you think we should mention it in the README as well?
There was a problem hiding this comment.
Yes, seems like a breaking change that should stay, see for example what we did when requiring Develocity 2024.1 https://github.com/gradle/develocity-gitlab-templates?tab=readme-ov-file#requirements
There was a problem hiding this comment.
Agree, although I'd update a Readme at the time of release, as it might be confusing to have this mentioned already without a version available
Yes, the injection get's disabled after an upgrade as the configuration fields are no longer there and it triggers the "disable injection" code path. User's would need to specify the extension versions explicitly and re-enable it again |
* Download Maven extensions instead of bundling them * Set extension versions properly in test * Fix Gradle Enterprise extension selection * Fix acceptance tests * Revert back the maven version for test * Revert README change for a separate pull request
This PR removes the bundling of Develocity and CCUD Maven extensions.
Instead, the extensions are now downloaded from Maven Central. This enables the user to specify the version of the extensions they need and keep using the same plugin version.
This change is not backwards compatible and users would need to explicitly specify the extension versions after an upgrade.