[
https://issues.apache.org/jira/browse/SOLR-17602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17916177#comment-17916177
]
Christos Malliaridis commented on SOLR-17602:
---------------------------------------------
I would consider PR #2925 as pre-work that had to be done in order to proceed.
It is indeed not satisfying the description of this issue, but provide now a
good foundation to work on this. This is also the reason I haven't resolved the
issue.
In order to address the issue, we need to understand how the lib directories
are populated for each module. From what I believe, we use the {{runtimeLibs}}
configurations, then, exclude all jars that belong to the project's modules and
also all jars that are included in the {{solrPlatformLibs}} (which are all jars
from {{{}core{}}}, {{{}solrj{}}}, {{{}api{}}}, {{solrj-zookeeper}} and a few
other modules I believe).
This logic is coded in {{{}:solr:packaging{}}}. Now, what I am not sure is,
would it be sufficient to find a way to list in the generated txt file (that is
probably per module?) the jars that are included in each module from the
{{assemble}} step?
> 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: 1h
> 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]
