Some NOTICE.txt files are 0-bytes, but not all that many. I was counting that in my original "~150" estimate.
"find . -name "*NOTICE*" | wc -l"....reports 163 NOTICE files "find . -empty | grep NOTICE | wc -l"...reports that 15 NOTICE files are empty So that leaves _nonempty_ 148 NOTICE files in 'solr/licenses'- only 40ish of which are recorded in 'solr/NOTICE.txt'. On Mon, Apr 12, 2021 at 1:55 PM Mike Drob <[email protected]> wrote: > > Many of the notices that we have there are zero bytes. > > The top level aggregate notice is part of asf release policy iirc. > > On Mon, Apr 12, 2021 at 12:52 PM Jason Gerlowski <[email protected]> > wrote: >> >> > Why do we need a jar dependency? >> We don't. Just the "normal" dependency on a java library that's >> distributed through maven central, etc. Sorry if my wording suggested >> otherwise. >> >> > If the dependency you are using has a NOTICE file, then we need to >> > preserve that content in our own NOTICE file >> >> AFAICT, ASL section 4d doesn't say _where_ the NOTICE content needs to >> live, does it? And we're already including a NOTICE.txt entry for >> each dependency in the 'solr/licenses/' directory. [1] Isn't the >> content of 'solr/licenses/' sufficient to meet 4d? If not, have the >> majority of our deps been added incorrectly? (40ish in >> solr/NOTICE.txt, ~150 in 'solr/licenses/') >> >> [1] https://github.com/apache/solr/tree/main/solr/licenses >> >> On Mon, Apr 12, 2021 at 1:42 PM Ishan Chattopadhyaya >> <[email protected]> wrote: >> > >> > Why do we need a jar dependency? Is the artifact not available through >> > maven central? IIRC, @Uwe Schindler once mentioned that we should avoid >> > adding jar files to the project. >> > >> > On Mon, 12 Apr, 2021, 11:03 pm Mike Drob, <[email protected]> wrote: >> >> >> >> If the dependency you are using has a NOTICE file, then we need to >> >> preserve that content in our own NOTICE file (see Apache Licence section >> >> 4d) >> >> >> >> I imagine the intent was to make sure we are using compatible licenses >> >> according to the ASF release policies which defines category A/B/X and >> >> also to be aware of the transitive dependencies that we might be bringing >> >> in. >> >> >> >> On Mon, Apr 12, 2021 at 12:18 PM Jason Gerlowski <[email protected]> >> >> wrote: >> >>> >> >>> Hey all, >> >>> >> >>> I have a PR open that needs access to a new JAR library, so I've been >> >>> trying to understand the full set of steps involved in adding a >> >>> dependency to Solr. I followed the steps mentioned in >> >>> `help/dependencies.txt` (i.e. 'gradlew helpDependencies') without too >> >>> much trouble: the JAR is visible on the classpath and the >> >>> 'solr/licenses/' directory has the appropriate checksum, license and >> >>> NOTICE.txt files. Everything looks good. >> >>> >> >>> Just when I thought I was done though, I noticed one more step in >> >>> 'solr/licenses/README.committers.txt': >> >>> >> >>> > Under no circumstances should any new files be added to this directory >> >>> > without careful consideration of how LICENSE.txt and NOTICE.txt in the >> >>> > parent directory should be updated to reflect the addition. >> >>> >> >>> Does anyone remember the context around this step, and whether it is >> >>> still valid today? It seems like it might be outdated, but maybe not. >> >>> >> >>> If appending to the top-level NOTICE.txt is still required: under what >> >>> conditions? 'solr/NOTICE.txt' only has a NOTICE.txt file for ~40 >> >>> dependencies: conspicuously few compared to the ~150 non empty >> >>> NOTICE.txt files in the 'solr/licenses/' directory. >> >>> >> >>> Appreciate any context people can offer here: just looking to make >> >>> sure I get the process right. >> >>> >> >>> Best, >> >>> >> >>> Jason >> >>> >> >>> --------------------------------------------------------------------- >> >>> To unsubscribe, e-mail: [email protected] >> >>> For additional commands, e-mail: [email protected] >> >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
