[ 
https://issues.apache.org/jira/browse/SOLR-17602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18050879#comment-18050879
 ] 

Jan Høydahl commented on SOLR-17602:
------------------------------------

I'm not sure a jars.txt file to check into git is the best end goal here, 
although I see how that could be conventient to track changes in that one file.

We have the solr/licenses folder which already tracks all the jars (including 
license) that will be pulled by our build. So in PRs I am always alert to 
changes in that folder, meaning there are changes in deps.

A major problem with the licenses folder is that it includes test dependencies, 
which are never shipped in a tarball. I filed SOLR-15465 to address it, and if 
we manage to tweak the licenses/updateLicenses gradle tasks so that it only 
considers jars that will be shipped in our tarballs, we'd achieve the same end 
goal
 * One location (solr/licenses) to track changes to shipped jars
 * Shrink that huge list to those we actually ship

And as a followup we could do SOLR-15929 and start generating our LICENSE and 
NOTICE files so they pull in only what is correct for the full and slim 
tarballs that we do ship.

If you agree this could be a way to achieve the same, this can be re-purposed 
and resolved as per-mod dependency-locking only.

> 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 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]

Reply via email to