cool; thanks. On Thu, Sep 3, 2026 at 4:27 AM Jan Høydahl <[email protected]> wrote:
> > (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. > > The current license bookkeeping is based on jar-file names/prefixes. > And the reason for jarPrefixes is the same - we need to account for all > jar files > and each one needs to be linked to a LICENSE+NOTICE. In this proposed > scheme, > such metadata sits in the YAML registry file, and jarPrefixes is the link > to make sure > all jars are connected to a LICENSE/NOTICE/COPYRIGHT and that there are no > dangling registry entries without any bundled jar. > > Using file names is fast and good enough as long as there is no complete > name overlap. > > > (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? > > Re-written table to make it less confusing. The right column is now "How > it's kept current". > > For solr's own published JAR files, "committed" meant that we stuff the > already > committed LICENSE/NOTICE files as used by src dist into each produced > jar file's META-INF. We could have tailored them per produced jar, but > keeping > that out of the equation in first design. > > > 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. > > The "check" phase is designed for speed, just as the current "licenses" > task. > It will read the yaml manifests, then do a two-way check that > - every jar we ship is associated with a license > - every dep in the registry is (still) shipping > > This will all be done through jar-file names, linked through "jarPrefixes" > and static parsing > of gradle lock files, not building of distribution or expensive operations. > > Jan > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
