SOLR-17602: Per-Module Dependency Locking #2925
Conversation
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.
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.
|
+1 More gradle-default behavior is better, if we can make it jive with our project requirements.. Especially when the plugin in use (carrot) is not that actively maintained. |
…r-module-dependency-locking # Conflicts: # versions.lock
| In case it is a transitive dependency that is not directly used, you can simply add it to `libs.versions.toml` as you | ||
| would with any other dependency. The dependency resolution approach defined in `:platform` will handle the rest. | ||
| Don't forget to add a `# @keep` note with a reference to the vulnerable version and CVE that is fixed with the explicit | ||
| definition of the library and new version. This way it is easier to keep track of unreferenced dependencies in our | ||
| libraries toml file, and we can clean them up once the libraries using the modules are updated. |
There was a problem hiding this comment.
Ooooh, now I see what this is for.
| @@ -20,6 +20,7 @@ apply plugin: 'java-library' | |||
| description = 'SQL Module' | |||
|
|
|||
| dependencies { | |||
| implementation platform(project(':platform')) | |||
There was a problem hiding this comment.
The explicit-ness of this is good, I think, even if it means an additional line everywhere. Maybe another different approach would be for the build to insert these automatically. Either is fine.
This task dependency seems to not have the expected effect.
…king # Conflicts: # dev-tools/scripts/smokeTestRelease.py # versions.lock
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.Additional Notes
When generating lockfiles under Windows, the lockfiles may use CRLF instead of LF and display difference in IDE. If you have configured your Git correctly, you may ignore the changes.
Additionally, the caching in CI/CD uses
versions.lockfor index, which with this PR would not exist anymore. Since this PR uses per-module dependency lockfiles, this commit updates the workflows to use all lockfiles as keys.I have also noticed that when running
./gradlew assemblethe lockfiles are ignored for some reason and different libraries are included. Adding theplatformmodule explicitly viaimplementation platform(project(":platform")solves the issue. So it may be necessary to include the platfform module in all modules and submodules explicitly to ensure the consistency in the future.Tests
Effects tested with lucene version update in
mainwhile this PR was open.Checklist
Please review the following and check all that apply:
mainbranch../gradlew check.