dsmiley commented on code in PR #2925:
URL: https://github.com/apache/solr/pull/2925#discussion_r1912079520
##########
solr/modules/sql/build.gradle:
##########
@@ -20,6 +20,7 @@ apply plugin: 'java-library'
description = 'SQL Module'
dependencies {
+ implementation platform(project(':platform'))
Review 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.
##########
dev-docs/dependency-upgrades.adoc:
##########
@@ -30,43 +30,40 @@ In order to upgrade a dependency, you need to run through a
number of steps:
1. Identify the available versions from e.g. https://search.maven.org[Maven
Central]
2. Update the version in `gradle/libs.versions.toml` file
-3. Run `./gradlew writeLocks` to re-generate `versions.lock`. Note that this
may cause a cascading effect where
+3. Run `./gradlew resolveAndLockAll` to re-generate lockfiles. Note that this
may cause a cascading effect where
the locked version of other dependencies also change.
4. In case of a conflict, resolve the conflict according to
`help/dependencies.txt`
-5. Check if there are any constraints that are obsolete after the dependency
update
-6. Update the license and notice files of the changed dependencies. See
`help/dependencies.txt` for
- details.
-7. Run `./gradlew updateLicenses` to re-generate SHA1 checksums of the new jar
files.
-8. Once in a while, a new version of a dependency will transitively bring in
brand-new dependencies.
+5. Update the license and notice files of the changed dependencies. See
`help/dependencies.txt` for details.
+6. Run `./gradlew updateLicenses` to re-generate SHA1 checksums of the new jar
files.
+7. Once in a while, a new version of a dependency will transitively bring in
brand-new dependencies.
You'll need to decide whether to keep or exclude them. See
`help/dependencies.txt` for details.
-=== Reviewing Constraints
+=== Constraints and Version Alignment
-The constraints are defined in gradle/validation/dependencies.gradle. There,
if the updated dependency is listed,
-the constraint can be reviewed, updated or removed.
+To sync the version of direct and transitive dependencies across the project,
we iterate in the `:platform` module
+over the libraries defined in `gradle/libs.version.toml` and add them as
constraints. Then, we use the module in
+main modules like `:solr:api` and `:solr:core` and transitively pass down to
all other modules the constraints.
-The constraints fall into two "groups". In the first group there are
dependency constraints from dependencies
-that our project directly includes and require version alignment to sync the
versions across all transitive
-dependencies. In the second group are dependencies that are only present as
transitive dependencies.
-There, we try to follow the convention to provide additional information with
"which dependencies use what version",
-so that the next person reviewing the constraint does not have to look it up.
However, this is quite time-consuming
-to analyze the dependencies and therefore subject to change.
+If a new module does not depend on another module that already includes
`:platform` as a platform dependency, it should
+explicitly add it to sync the versions with the rest of the project.
`:solr:server` is one case where this is necessary.
-In order to review a constraint, you have to check if the updated dependency
is mentioned in any of the constraints,
-either as a reason for another dependency constraint or as the constraint's
dependency. Removing temporarily
-a constraint, the task writeLocks will fail if the constraint is still
required.
+=== Addressing Security Vulnerabilities
-This process and the constraints of dependencies.gradle are not optimal, as it
is quite time-consuming and not obvious
-by just looking at it. We just haven't found yet a more efficient way to
maintain these constraints.
+When it comes to security vulnerabilities that are found in direct or
transitive dependencies, the recommended way to
+address them is to update the specific library if there is a new release that
solves this issue. For both direct and
+transitive dependencies, we simply have to update the version as described
above.
-== Renovate bot Pull Requests
+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.
Review Comment:
Ooooh, now I see what this is for.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
