malliaridis commented on code in PR #2706: URL: https://github.com/apache/solr/pull/2706#discussion_r1841589725
########## help/dependencies.txt: ########## @@ -100,12 +166,12 @@ If you want to upgrade Lucene to a newer build proceed like the following: queued) - remember the build number of Jenkins (left side, first build in list, prefixed by '#') -- Edit ./versions.props and change Lucene's version to '9.0.0-prereleaseX', +- Edit gradle/libs.versions.toml and change Lucene's version to '9.0.0-prereleaseX', Review Comment: When I started these changes I wasn't sure how Lucene is updated. We still have some custom logic in some gradle files (see `gradle/lucene-dev/*`), and I believe now that Lucene is "just another dependency", we may be able to simplify and remove any custom logic related to Lucene versions. But this should be handled in a separate PR. ########## dev-docs/dependency-upgrades.adoc: ########## @@ -16,30 +16,34 @@ // specific language governing permissions and limitations // under the License. -Solr has lots of 3rd party dependencies, defined mainly in `versions.props`. +Solr has lots of 3rd party dependencies, defined in `gradle/libs.versions.toml`. Keeping them up-to-date is crucial for a number of reasons: * minimizing the risk of critical CVE vulnerabilities by staying on a recent and supported version * avoiding "dependency hell", that can arise from falling too far behind -Read the https://github.com/apache/solr/blob/main/help/dependencies.txt[help/dependencies.txt] file for an in-depth explanation of how gradle is deployed in Solr, using -https://github.com/palantir/gradle-consistent-versions[Gradle consistent-versions] plugin. +Read the https://github.com/apache/solr/blob/main/help/dependencies.txt[help/dependencies.txt] file for an in-depth +explanation of how dependencies are managed. == Manual dependency upgrades 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 `versions.props` file -3. Run `./gradlew --write-locks` to re-generate `versions.lock`. Note that this may cause a cascading effect where +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 the locked version of other dependencies also change. -4. Run `./gradlew updateLicenses` to re-generate SHA1 checksums of the new jar files. -5. Once in a while, a new version of a dependency will transitively bring in brand-new dependencies. +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 Review Comment: The constraints are defined in `gradle/validation/dependencies.gradle`. There, if the updated dependency is listed, the constraint can be reviewed, updated or removed. The constraints fall into two "groups". The first group are dependency constraints from dependencies that our project directly includes and require version alignment to sync the versions across all transitive dependencies. The second group are dependencies that are only present as transitive dependencies. There, I followed 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. Now, 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 required. 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. -- 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
