Merged
Conversation
Member
Author
|
@bot-gradle test this |
jvandort
requested review from
a team,
6hundreds,
bamboo and
big-guy
and removed request for
a team
This comment has been minimized.
This comment has been minimized.
Collaborator
|
The following builds have passed: |
jvandort
commented
May 30, 2025
| DomainObjectContext domainObjectContext, | ||
| String name, | ||
| ConfigurationsProvider configurationsProvider, | ||
| boolean isDetached, |
Member
Author
There was a problem hiding this comment.
Lets inline false for all these role locked configurations
big-guy
approved these changes
May 30, 2025
Prior to this change, the root variant produced by a resolvable configuration would always live in the same component used to advertise the variants produced by the consumable configurations of a dependency management instance. There are three scenarios to consider here 1. A buildscript, or other use of DependencyManagementServices#newDetachedResolver These dependency management instances have no variants 2. A project. These dependency management instances have variants 3. A detached configuration. For scenarios 1 and 3, the root variant is now placed in a root component that is identified by a RootComponentIdentifier. Previously, for scenario 1, we identified the component as unspecified:unspecified:unspecified, and for scenario 3, we identified the component as the same identifier as the project. By putting project detached configurations in a separate component, they are now able to resovle dependencies that target the project they live witin. In the future we also want to do this for scenario 2, where the root variant of resolutions within a project also live within some adhoc root component. In practice, the root variant is not a real variant of the project component, but some virtual variant. As a result, resolvable configurations in projects are not able to resolve other versions of that same project. This is likely a more significant change than for buildscripts and detached configurations, so we will start with this set of changes and see how the ecosystem handles these changes
These will always be detached. Only legacy configurations are created as detached
jvandort
force-pushed
the
jvandort/dm/introduce-root-component-identifier
branch
from
1766dcc to
b428314
Compare
Collaborator
|
WARN: Based on labels, this pull request addresses notable issue but no changes to release note found. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Prior to this change, the root variant produced by a resolvable configuration would always live in the same component used to advertise the variants produced by the consumable configurations of a dependency management instance.
There are three scenarios to consider here
For scenarios 1 and 3, the root variant is now placed in a root component that is identified by a RootComponentIdentifier. Previously, for scenario 1, we identified the component as unspecified:unspecified:unspecified, and for scenario 3, we identified the component as the same identifier as the project.
By putting project detached configurations in a separate component, they are now able to resolve dependencies that target the project they live within.
In the future we also want to do this for scenario 2, where the root variant of resolutions within a project also live within some adhoc root component. In practice, the root variant is not a real variant of the project component, but some virtual variant. As a result, resolvable configurations in projects are not able to resolve other versions of that same project. This is likely a more significant change than for buildscripts and detached configurations, so we will start with this set of changes and see how the ecosystem handles these changes
Fixes #9591
Fixes #30320
Reviewing cheatsheet
Before merging the PR, comments starting with