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: issues-unsubscr...@solr.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org

Reply via email to