SOLR-17602: Per-Module Dependency Locking #2925
Draft
Conversation
This file contains 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
The platform module includes all dependencies from the version catalog as constraints and is added to the root modules as API for transitive inheritance of the constraints.
…ndency-resolution
Removes carrot-search dependencychecks plugin
github-actions
bot
added
documentation
|
@dsmiley does this go to the right direction in regards to your ticket? |
In the gradle documentation and in general, lockfiles are generated via ./gradlew dependencies --write-locks. This commit fixes the issue where the dependencies task is used instead of the resolveAndLockAll for lockfile generation and the lockfiles are not properly updated.
dsmiley
approved these changes
Jan 5, 2025
There was a problem hiding this comment.
does this go to the right direction in regards to your ticket?
Yes but definitely doesn't solve them. I like that this PR makes it easy to know if a dependency is on a certain configuration/classpath without having to google the gradle command to accomplish the same. And if we change the dependencies, we might notice unanticipated changes.
The error-prone aspect is unfortunate. I wonder if we're disabling error-prone by default in the wrong way.
+1 to this PR.
| }.findAll { | ||
| // Do not depend on disabled tasks or tasks that do not exist | ||
| // :platform module does not have a renderJavaDoc and therefore task is null | ||
| it != null && it.enabled == true |
There was a problem hiding this comment.
in groovy I think this can be it?.enabled == true and maybe not even need the == true part
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
https://issues.apache.org/jira/browse/SOLR-17602
Description
To improve the developer experience of the dependency management, we are looking for solutions to make the dependency lock files more developer-friendly / readable.
Solution
This solution is based on #2915 which introduces a platform module for aligning the dependency version across our project via constraints.
This PR removes the carrotsearch dependencycheck plugin and falls back to the default gradle tasks for generating lockfiles. It defines a new task that can be used via
gradlew resoslveAndLockAll --write-locks. This task generates or updates existinggradle.lockfilein each module.Additional gradle configuration has been added to lock all module configurations by default. The task
resolveAndLockAllwill then filter and lock only the resolveable dependencies.PR should update documentation before merging (in case this solution is considered).
gradlew resoslveAndLockAll --write-locks -Pvalidation.errorprone=true. Explicitly enabling is not recommended, as there are other tasks that may fail as well if errorprone is not explicitly enabled.Tests
Not tested yet.
Checklist
Please review the following and check all that apply:
mainbranch../gradlew check.