I think we have the same problem in Taverna, as there will be several binary packages (command line, workbench, server), but they will share many artifacts.
So I guess the conclusion for us here is to just do them manually.. as much as I dislike another manual thing to maintain :) As they build on each-other then we can just have headings like "# Taverna Engine notices" inside to make it easier to copy-paste that bit of the file around on any updates. I am not quite sure exactly where to store these files Maven-wise so this works on the top-level pom project for each repository. Perhaps we can't use the source distribution we inherit from Apache Parent and have to do separate "apache-taverna-language" modules etc to make the source artifacts? On 11 February 2015 at 09:34, Andy Seaborne <[email protected]> wrote: > On 10/02/15 17:04, Stian Soiland-Reyes wrote: >> >> Jena does this manually, which I've already gotten into trouble because >> of..:-) > > > Different parts of Jena need different NOTICE/LICENSE text. > > Each binary jar should have N&L specific to it's inputs. > > Uber jars are different again because of the rolling up of other systems. > > The source release contains things not in any jar (test files for example). > W3C test files have LICENSE placed next to the relevant suites (and which is > now how W3C distribute their own material for RDF and SPARQL because I got > them to dual-license properly). > > Without commonality, automation is zero gain but the contents rarely change > so maintenance is a once-a-year perl script for any copyright years. > > Andy -- Stian Soiland-Reyes Apache Taverna (incubating) http://orcid.org/0000-0001-9842-9718
