(sorry for the slow reply) On Wed, 2008-04-30 at 23:16 +0100, Ross Gardler wrote: > I have a very rough implementation of licence appending in RAT, that is, > you can optionally add licence headers to files that do not currently > have a recognised licence header and are not in the excludes list.
cool > The implementation is very limited (only able to ad Apache Software > Licence, only works on java files), but it is a starting point. yep > Before I go an submit a patch I'd like to float the design past people > here. I like to work in a "get things working then refactor" kind of > way. Is that how you want to work here, or do you prefer a more rigorous > upfront design? either way works for me ;-) > Anyway, here's what I have done: > > Added Apache CLI to the Report class. The current help message is: > > usage: simal [options] DIR > Options > -a,--addLicence Add the default licence header to any file with > an unknown licence that is not in the exclusion list, and exit. > > -c,--copyright <arg> The copyright message to use in the licence > headers, usually in the form of "Copyright 2008 Foo" > > -h,--help Print help for the RAT command line interface > and exit > > -x,--xml Output the report in XML format sounds good > Adding the --addLicence option results in the followig behaviour: > > - run the report, capturing the XML output > - extract all files with no licence > - create a rat.appender.LicenceAppender class > - iterate over all files calling the append method of the LicenceAppender > - re-run the report and output in either text or xml (if --xml option is > specified) > > The LicenceAppender will (if the file is a java file) either add the > standard ASF header, or, if the instance was created using an argument > from the --copyright command line option, the correct header of applyig > the Apache Software Licence with a named copyright holder. > > Currently the LicenceAppender creates a new file with the licence > header, i.e. "test.java" generates a "test.java.new" alongside the > orgiinal file. cool > Potential refactoring: > > - make this a single pass process by adding a hooker into the analysis > thread. I didn't do it this way initially as I prefer a "get it working > then improve it approach" and besides, it seems wrong for an analysis > class to actually change the source files. It would seem this is a much > bigger refactoring. probably want to put an intercepter in the pipeline > - add an option to modify the java files themselves, i.e. don't create > "test.java.new". I think having the default set to create alternative > files is safer as this will allow for an additional sanity check before > actually modfiying the source sounds reasonable > - make LicenceAppender an abstract class and provide other appender > implementations for other licences > > - move the logic out of Report.main(args) and into LicenceAppender > (probably do that in a few minutes) > > So, is this something that you'd want in RAT? probably not in the engine RAT already has a number of quite different use cases. i don't see why another one shouldn't be added. may well want to spit out some modules on day and some of the use case specific code may end up in non-core modules. > Is it something you would > accept in its current rough design? i think so > One last question. What is the policy for code submissions with respect > to unit tests. I've been lazy on this and not written unit tests. I'd be > happy to write them before submitting, but if I get to carry on being > lazy, I will. i'm very test driven as are most of the contributors. the missing part of the jigsaw is functional testing. not sure it's worthwhile creating unit tests for the sake of it but a small number of good functional ones would be worthwhile. - robert
