apply substitution only to configurations on java SourceSets #10
Conversation
Generate changelog in
|
|
👍 |
|
|
||
| public class JakartaPackageAlignmentPlugin implements Plugin<Project> { | ||
| @Override | ||
| public final void apply(Project project) { | ||
| project.getExtensions().getByType(SourceSetContainer.class).configureEach(sourceSet -> { |
There was a problem hiding this comment.
perhaps withPlugin to ensure SourceSetContainer exists?
There was a problem hiding this comment.
should we be using withPlugin on java, java-library, or both?
There was a problem hiding this comment.
Is java-base sufficient? I think it's an ancestor of both.
There was a problem hiding this comment.
that'll probably work, it technically looks like it comes from JvmEcosystemPlugin: https://github.com/gradle/gradle/blob/master/subprojects/plugins/src/main/java/org/gradle/api/plugins/JvmEcosystemPlugin.java#L57
There was a problem hiding this comment.
and also, looks like java-library will apply java as well, so i think either java or java-base should be sufficient
|
|
||
| project.getPluginManager().withPlugin("com.palantir.consistent-versions", _plugin -> { | ||
| // necessary to get g-c-v to write substituted dependencies to the versions.lock file | ||
| project.getConfigurations().getByName("unifiedClasspath", this::configureConfigurationForSubstitution); |
There was a problem hiding this comment.
I wonder if we need something along these lines depending on the order things are applied?
(I defer to @CRogers on this sort of thing, though)
project.getConfigurations().configureEach(new Action<Configuration>() {
@Override
public void execute(Configuration config) {
if ("unifiedClasspath".equals(config.getName())) {
configureConfigurationForSubstitution(config);
}
}
});There was a problem hiding this comment.
hm, i guess? withPlugin guarantees that the action won't run until after the plugin is applied, and this configuration is created when the plugin is applied: https://github.com/palantir/gradle-consistent-versions/blob/develop/src/main/java/com/palantir/gradle/versions/VersionsLockPlugin.java#L220-L226
| project.getPluginManager().withPlugin("com.palantir.consistent-versions", _plugin -> { | ||
| // necessary to get g-c-v to write substituted dependencies to the versions.lock file | ||
| project.getConfigurations().getByName("unifiedClasspath", this::configureConfigurationForSubstitution); | ||
| }); | ||
| } |
There was a problem hiding this comment.
Awareness of specific dependency plugins seems like a bug that may come back to haunt us. I don't know of a better option, but we should make sure we understand why this is necessary.
There was a problem hiding this comment.
Agreed, this feels hacky.
I just found this (see: https://docs.gradle.org/current/userguide/resolution_rules.html#sec:dependency_substitution_rules):
Adding a dependency substitution rule to a configuration changes the timing of when that configuration is resolved. Instead of being resolved on first use, the configuration is instead resolved when the task graph is being constructed.
So I wonder if the dependency substitution rules on e.g. runtimeClasspath isn't getting picked up when unifiedClasspath is resolved because the dependencies/constraints are copied to that configuration before the task graph is constructed?
No description provided.