I was just thinking about doing something similar for plug-ins, ie -
maven.plugin.torque.propertyname and then convert it to the proper
configurable torque property. Taking it a step further I started thinking
about Torque itself and how it uses a Mapping file to help with all of the
database specific stuff, so it wouldn't have to be hard-coded.
What does everyone think?
-warner
----- Original Message -----
From: "Pete Kazmier" <[EMAIL PROTECTED]>
To: "maven dev" <[EMAIL PROTECTED]>
Sent: Wednesday, May 29, 2002 4:56 AM
Subject: Re: JRefactory / Checksource Integration
> On Wed, May 29, 2002 at 09:42:34AM +0100, Nathan Coast wrote:
> > latest version of the Jrefactory integration after feedback from
> > maven-dev.
>
> After looking at the implementation, would the Builder pattern be useful
> in this situation? The Director would read the Maven source properties
> (the common denominator between checkstyle and jrefactory, as well as
> the checkstyle and jrefactory specific properties), then we could have
> an interface called PropertyConverter and have concrete implementations
> called CheckstylePropertyConverter and JRefactoryProeprtyConverter. The
> object produced by the PropertyConverter is a Properties object with the
> specific tool-specific properties. The Director would look something
> like:
>
> public class Director
> {
> private PropertyConverter converter;
>
> public Director(PropertyConverter converter)
> {
> this.converter = converter;
> }
>
> public void readProperties(Properties mavenSourceProps)
> {
> for (Enumeration e = mavenSourceProps.getProperties();
e.hasMoreElements(); )
> {
> String property = (String) e.nextElement();
>
> // Convert the brace policy to the specific properties
> // required by either Checkstyle or JRefactory depending on
> // what concrete PropertyConverter was passed into the
> // Director.
> if (property.equals("maven.sourcedef.bracepolicy"))
> {
>
converter.convertBracePolicy(mavenSourceProps.getProperty(property));
> }
> else if
(property.equals("maven.sourcedef.someOtherCommonProperty"))
> {
>
converter.convertOtherCommonProperty(mavenSourceProps.getProperty(property))
;
> }
>
> // Pass thru checkstyle specific stuff untouched.
> else if (property.startsWith("maven.checkstyle."))
> {
>
converter.passThru(mavenSourceProps.getProperty(property));
> }
>
> // Pass thru jrefactory specific stuff untouched.
> else if (property.startsWith("maven.jrefactory."))
> {
>
converter.passThru(mavenSourceProps.getProperty(property));
> }
> }
> }
> }
>
> public interface PropertyConverter
> {
> public void convertBracePolicy(String);
> public void convertOtherCommonProperty(String);
> public void passThru(String);
> }
>
> public class CheckstylePropertyConverter implements PropertyConverter
> {
> Properties checkstyleProps = new Properties();
>
> public void convertBracePolicy(String value)
> {
> if (value.equals("PASCAL"))
> {
> checkstyleProps.setProperty("lcurlyType", "nl");
> checkstyleProps.setProperty("rcurlyType", "nl");
> }
> else (value.equals("OTHER"))
> {
> checkstyleProps.setProperty("lcurlyType", "same");
> checkstyleProps.setProperty("rcurlyType", "same");
> }
> }
>
> public void convertOtherCommonProperty(String);
> public void passThru(String);
>
> public Properties getProperties()
> {
> return checkstyleProps;
> }
> }
>
> I just thought this seemed like a good place to use the Builder pattern.
>
> > FYI, running the maven:pretty-print target reduces checksource errors
> > from 5K to 1K.
>
> Cool!
>
> > Should we be autogenerating javadoc? whilst reduces checkstyle errors,
doesn't
> > neccessarily improve the code?
>
> I don't think we should auto-generate the javadoc cuz it will mask the
> fact that there is no real javadoc in the source, thus, no motivation to
> fix it.
>
> > Should we autogenerate @author tags? If a file is missing the @author
> > tag, the user who runs the pretty-print task will have their username
> > inserted as the author. Only a problem if there is a significant
> > number of files missing the @author tag.
>
> I don't think we should auto-generate the @author tags because that
> would be misleading.
>
>
> --
> To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>
>
>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
