-
Notifications
You must be signed in to change notification settings - Fork 4.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow applying plugins with matching versions #19015
Allow applying plugins with matching versions #19015
Conversation
This resolves a long-standing issue with applying a plugin in a subproject when that same plugin is already applied in the root project. Prior to this commit, you would need to avoid specifying a version, which only became a true hassle with the introduction of plugins in the version catalog, as shown in #18236. This commit does not attempt to resolve conflicting versions, or inspect the classpath for a plugin version. It only records the data that Gradle knows for sure, and uses that to slightly relax this check. It is sufficient to allow the issue mentioned prior to be resolved.
subprojects/core/src/main/java/org/gradle/api/internal/initialization/ClassLoaderScope.java
Outdated
Show resolved
Hide resolved
Awesome that you found a way to collect applied plugin versions! I just left a comment regarding having a direct dependency on plugins in ClassLoaderScope. One question: Could we add also functionality to define "withoutVersion" plugins in the Version catalog? |
...posite-builds/src/main/java/org/gradle/composite/internal/plugins/LocalPluginResolution.java
Show resolved
Hide resolved
subprojects/core/src/main/java/org/gradle/api/internal/initialization/ClassLoaderScope.java
Outdated
Show resolved
Hide resolved
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One question about the added state and a minor release note comment.
For documentation, have a look at https://docs.gradle.org/current/userguide/plugins.html#sec:subprojects_plugins_dsl. Maybe adding a note there makes sense and linking to that section from https://docs.gradle.org/current/userguide/platforms.html#sec:plugins would improve the situation.
...ects/core/src/main/java/org/gradle/api/internal/initialization/AbstractClassLoaderScope.java
Outdated
Show resolved
Hide resolved
So it doesn't introduce overhead when loading from the configuration cache.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
@asodja re:
I did not tackle this in this PR, we have decided to save it for later. I filed #19302 to track this. |
OK, I've already triggered a build for you. |
Pre-tested commit build failed. |
@bot-gradle test and merge |
OK, I've already triggered a build for you. |
This resolves a long-standing issue with applying a plugin in a
subproject when that same plugin is already applied in the parent project.
Prior to this commit, you would need to avoid specifying a version,
which only became a true hassle with the introduction of plugins in the
version catalog, as shown in #18236.
This commit does not attempt to resolve conflicting versions, or inspect
the classpath for a plugin version. It only records the data that Gradle
knows for sure, and uses that to slightly relax this check. It is
sufficient to allow the issue mentioned prior to be resolved.
Replaces #18728
Fixes #18236
If accepted, I'll do the following: