On 18 March 2012 16:05, Jeremy Boynes <jboy...@apache.org> wrote: > It looks like the source assembly that packages the source distributions will > prefer files in the project over files from the remote resources bundle. So > is we rename LICENSE.txt to just LICENSE there will only be one copy and it > will be the one from this project. I'm going to do that for the files in the > root of each trunk so that they will be in the top level of anything checked > out from SVN, and remove the ones further down the directory tree leaving it > to the plugin to add them to each distribution. If in the future we add > dependencies with notice requirements we can add that to the particular > module at that time.
OK, great. > On Mar 4, 2012, at 5:40 PM, sebb wrote: > >> On 4 March 2012 03:44, Jeremy Boynes <jboy...@apache.org> wrote: >>> On Feb 29, 2012, at 11:37 AM, sebb wrote: >>> >>>> On 29 February 2012 19:15, Olivier Lamy <ol...@apache.org> wrote: >>>>> Perso, I prefer using something which read pom and generate >>>>> automatically N&L from metadatas rather than maintaining those files >>>>> manually (for me manually means you always missed to add/modify :-) ) >>>>> (but sure it's my POV) >>>> >>>> AFAICT that just moves the work from maintaining the N&L to creating >>>> and maintaining the metadata. >>>> >>>> It also means that the N&L files are not present in SVN (unless they >>>> are checked in after generation). >>> >>> My preference here is also to have them generated. We want the metadata in >>> the project descriptor to be valid anyway, and maintaining the templates >>> for LICENSE and NOTICE would be handled by maintainers of the Apache >>> resources. We don't have any dependencies requiring a notice, and if we do >>> this should be covered with append-resources. >>> >>> The files wouldn't be in SVN but will be in the distributed archives. >>> Having this done automatically rather than by configuring each archiver >>> will be easier to keep straight. >> >> I think just about every project has N&L files at the top-level of SVN. >> [If they don't, perhaps they should] >> >> Not sure it is an absolute requirement (unlike in archives and jars) >> but it is helpful for 3rd parties who browse the SVN tree. >> >>> -- >>> Jeremy >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org >>> For additional commands, e-mail: dev-h...@tomcat.apache.org >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: dev-h...@tomcat.apache.org >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
