from musings:
<SNIP>
It would be nice to integrate the way checkstyle, JRefactory and other tools
like that work from some sort of source definition. I believe the project object
model can store this information and we can make little adapters to work with
the various configuration file formats for the various tools that are available
for use.
</SNIP>
a few thoughts:
1) There should be a shared configuration somewhere under maven-home that
defines how checkstyle and jrefactory behave for all projects.
2) An individual project should be able to override the maven-home configuration.
3) An individual project should be able to override the shared config with
separate configurations for checkstyle and jrefactory. Could result
in jrefactory creating code that checkstyle complain about, but I guess maven
shouldn't restrict what developers want to do.
As I'm relatively new to maven, I'm not so sure where I should put these
configurations. At the moment, the checkstyle properties are
in ${maven.home}/default.properties. Where should these values be placed if
they are to be stored in the pom as mentioned in the musings - props file, xml?
Also what is involved in getting a source definition into the pom?
JRefactory loads its config from a file, so I assume the adapter will have to
write the appropriate contents of the pom to a file and configure the
PrettyPrinter with the location of that file.
I ran a few tests on some particularly bad code and the pretty printer reduced
the checkstyle errors from 490 to 110 with the out-of-the-box jrefactory
configuration - not bad!
Having compared what you can configure in checkstyle and jrefactory there are
about 80 parameters in total. Only about 10 will require sharing to ensure that
code generated by jrefactory will pass checkstyle tests.
Any of this a good / bad idea? or any other ideas about this area?
cheers
Nathan
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
