Thanks for tackling this! Some questions:
(A) jarPrefixes: I'm suspicious of the sight of this. I suspect the process is trying to infer to origin/identify of a JAR based on its name? A better way to identify a JAR is using the META-INF (manifest) information inside it, not by the name of the JAR. (B) Table "What each release artifact gets" confuses me, particularly the "Produced" column. Is Produced supposed to say what overall process produces the column to its left, the notice/license? Why then is "Maven jars" artfiact produced by "generated, committed". By "committed", I that's in source control. Generated by what? Maybe sometimes one, sometimes the other? One concern is that I don't want to see `check` phase doing excessive/expensive checking that could be deferred instead to either a PR validation or release manager activity, or of course if manually invoked (after touching dependencies). I *believe*, today it doesn't have to assemble the distributions. On Wed, Sep 2, 2026 at 2:59 PM Jan Høydahl <[email protected]> wrote: > Hi, > > I have an old JIRA SOLR-15929 < > https://issues.apache.org/jira/browse/SOLR-15929> titled "Clean up NOTICE > and LICENSE files for Solr" > > Basically we are shipping LICENSE/NOTICE files that are not aligned with > ASF policy. The shipped files are to reflect what is shipped in each > tarball. > > I have (ok, together with an LLM) written a Confluence page with a > proposed plan for improving this. Simply put, we'll generate these files > from a structured source of truth. > > Read the proposal at > https://cwiki.apache.org/confluence/spaces/SOLR/pages/449282855/SOLR-15929+ASF+compliant+NOTICE+and+LICENSE+files+in+dist > and comment here or in the associated JIRA. > > I have not started implementation, but this is a kind of task that is well > suited for AI assistance once we agree on the design. > > Jan
