[
https://issues.apache.org/jira/browse/SOLR-17602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18050870#comment-18050870
]
David Smiley commented on SOLR-17602:
-------------------------------------
I want to mention that I solved this at work for a project that has plugins
(with dependencies) to add to Solr. There's a small gradle snippet that
identifies the JARs it's going to add to Solr, and it writes a file list to a
text file that is already in source control. If it changed the file, it fails
the build with a message to insist this be scruitized.
{noformat}
// A kind of "dependency locking", scoped to the libs we add to Solr. We'd
like that as well BTW.
task checkLibsAndDeps(dependsOn: copyLibsForSolrHome) {
description = 'Validates that libs-and-deps haven\'t changed'
group = 'verification'
outputs.upToDateWhen { false } // Always run
def libsAndDepsDir = file("${buildDir}/libs-and-deps")
def committedFile = file("libs-and-deps.txt")
doLast {
def files = libsAndDepsDir.listFiles().findAll { it.isFile() }.collect
{ it.name }.sort()
def newText = files.join("\n") + "\n"
if (committedFile.text != newText) {
committedFile.text = newText
throw new GradleException("$committedFile was updated to reflect
dependency changes. Scrutinize this!")
}
}
}
check.dependsOn checkLibsAndDeps
{noformat}
> 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]
