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]>
