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