Any or all sounds good, I'm mostly wondering whether there's a way around having two sets of these files.
I love static analysis and style-checking. Warning automatically on violations is cool. Blocking commits sounds nice but in practice, these things turn up a few false positives that cause problems. So, y'know, I could live with just reports, so the interested can work on fixing up code when motivated. On Thu, May 27, 2010 at 3:01 PM, Benson Margulies <[email protected]> wrote: > Buildtools exists to support a classpath-based scheme for managing these > configs. It has some advantages as written up in the CXF-derived description > that I originally circulated, partially related to using the same configs in > maven and inside eclipse. If we are heading for 'checkstyle is a report, not > something we enforce,' then perhaps the eclipse configs are not that > important, and ..-ing our way to these from an etc dir is fine. This might > in turn allow removing buildtools altogether. What do people want out of > this? Do they want to preserve the enforcement option? > > On Thu, May 27, 2010 at 9:51 AM, Robin Anil <[email protected]> wrote: > >> I am also not sure about the build tools. But to answer the other >> question about the config xml files. Check the pom.xml in trunk. In >> the reporting section you will find the paths to all the xmls. They >> are the ones used to generate the reports and thus on hudson >> >> Robin >> >> >> >> On Thu, May 27, 2010 at 6:47 PM, Sean Owen <[email protected]> wrote: >> > The ones under buildtools/ are just identical to the ones under maven/ >> > though, what do you mean? (They're a subset of the files, actually.) >> > >> > Actually what is buildtools/ used for now, I'm not seeing what it does >> anymore. >> > >> > On Thu, May 27, 2010 at 2:10 PM, Robin Anil <[email protected]> >> wrote: >> >> I havent pointed all of them at maven. See the reporting section of the >> pom file >> >> >> > >> >
