latest version of the code, I'll document and provide patch files etc if the code is ok. btw this pattern > much cleaner code.
Pete Kazmier wrote:
> 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]>
>
>
sourcedef.zip
Description: Zip compressed data
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
