[
https://issues.apache.org/jira/browse/SOLR-17602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17907945#comment-17907945
]
Christos Malliaridis edited comment on SOLR-17602 at 12/23/24 8:55 PM:
-----------------------------------------------------------------------
I've reviewed the versions.lock again and noticed that:
* We have about 500 dependencies (transitive and not)
* We could reduce the versions.lock from 20k lines to 5k lines by changing
only the format of configurations
from \{ "configuration" : "testCompileClasspath", "projectPath" :
":solr:modules:scripting" }
to {{":solr:modules:scripting:testCompileClasspath"}}
* The current versions.lock uses configuration groups that may be reused for
multiple dependencies to reduce redundancy, but comes with the cost of
additional changes and re-organization of the groups if a dependency
(transitive and not) is added or removed from a module
The most interesting observation is that the gradle task "gradlew
[module]:dependencies --write-locks" generates a per-module lock file if we
enable dependency locking for all configurations in modules. This is probably
what we are looking for in SOLR-17603. This would also break down the huge
version.lock file into multiple gradle.lockfile. The only thing we would need
here is to simplify the locking by defining tasks that go through all modules
and updates locks / checks locks. I will create a draft PR for this, so that it
can be reviewed.
Update: I've linked [the PR|https://github.com/apache/solr/pull/2925] with this
issue fore review.
was (Author: JIRAUSER305622):
I've reviewed the versions.lock again and noticed that:
* We have about 500 dependencies (transitive and not)
* We could reduce the versions.lock from 20k lines to 5k lines by changing
only the format of configurations
from \{ "configuration" : "testCompileClasspath", "projectPath" :
":solr:modules:scripting" }
to {{":solr:modules:scripting:testCompileClasspath"}}
* The current versions.lock uses configuration groups that may be reused for
multiple dependencies to reduce redundancy, but comes with the cost of
additional changes and re-organization of the groups if a dependency
(transitive and not) is added or removed from a module
The most interesting observation is that the gradle task "gradlew
[module]:dependencies --write-locks" generates a per-module lock file if we
enable dependency locking for all configurations in modules. This is probably
what we are looking for in SOLR-17603. This would also break down the huge
version.lock file into multiple gradle.lockfile. The only thing we would need
here is to simplify the locking by defining tasks that go through all modules
and updates locks / checks locks. I will create a draft PR for this, so that it
can be reviewed.
> Maintain final JAR dependencies in source control to track changes
> ------------------------------------------------------------------
>
> Key: SOLR-17602
> URL: https://issues.apache.org/jira/browse/SOLR-17602
> Project: Solr
> Issue Type: Task
> Components: Build
> Reporter: David Smiley
> Priority: Major
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When we make changes to Solr's dependencies (add/remove/change), we edit our
> build files, and the code review process shows these changes to corresponding
> build files. However, what we all *really* want to know is the impact the
> change has on the artifacts our users consume. Almost nobody validates the
> impact; we hope for the best and find out of problems long later.
> This issue tracks one artifact: Solr's final assembly (any of the zip,
> tar.gz, or Docker). I propose committing to source control a machine
> generated file listing of the dependencies in a text file. This file shall
> be updated based on executing a gradle task TBD. When gradle "check" is run,
> it will henceforth ensure that this file hasn't been modified or doesn't
> match the output of the script's generation (details TBD).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
