On Mon, May 20, 2002 at 12:25:34PM +0100, Nathan Coast wrote:
> I've got an attempt at jrefactory / checksource integration. This is
> very much at the 'alpha' stage. I'd rather get some feedback from
> maven dev before completing / polishing the code.
Hi Nathan,
Sorry its taken me so long to provide some feedback on this, but I think
I like the idea we discussed in email better on how to make the
properties available to Ant vs extending the checkstyle task. For those
that are lost, My initial thoughts that I sent to Nathan regarding the
implementation of the checkstyle and jrefactory integration are included
at the bottom of this email. What did you think about this suggestion?
Thanks!
Pete
[pete's comments to nathan]
> I don't know how Jrefactory works, but if it can take its configuration
> via its Ant task like checkstyle does, then I think a simple class that
> just populates the Ant properties would be best (and easiest). For
> example, here is a made-up snippet of the Checkstyle task:
>
> <checkstyle
> lcurlyType="${maven.checkstyle.lcurly.type}"
> rcurlyType="${maven.checkstyle.rcurly.type}"
> ...
>
> Lets pretend that JRefactory could do something like this:
>
> <jrefactory
> bracePosition="${maven.jrefactory.brace.position}"
> ...
>
> So here is a made-up case where checkstyle has two parameters that
> specify brace position, and the corrsponding jrefactory has a single
> parameters. So you want to come up with a way to correlate these
> properties into a single config, right?
>
> I'd recommend that you create a common set of properties, perhaps,
> maven.source.* properties. There are the properties that users can
> override and extend just like we do with any other Maven properites
> (consistency is important). Then you can just take the values of those
> properties, and create the corresponding properties for checkstyle and
> jrefactory. So continuing with our example, lets pretend you have
> boiled the above checkstyle and jrefactory properties down to a
> maven.source.bracePolicy property.
>
> How would you pass this common property to the Checkstyle and Jrefactory
> specific Ant tasks? I would suggest that you implement something like
> this (see below). What is this? Its an Ant task that would be called
> before either the checkstyle or jrefactory tasks (above) get called. It
> sets up the specific properties for each program based on your boiled
> down properties.
>
> package org.apache.maven;
> import org.apache.maven.executor.AbstractExecutor;
>
> public class SourceProperties extends AbstractExecutor
> {
> public void execute() throws Exception
> {
> Iterator i = mavenSourceProperties.iterator();
> while (i.hasNext())
> {
> /*
> Pretend that SourceProperty is a class that represents
> the common property: mave.source.bracePolicy. This
> class can be queried to get the specific checkstyle and
> jrefactory properties. For example, to get the
> corresponding checkstyle properties (note: in our
> example, for the single maven.source.bracePolicy there
> are TWO corresponding checkstyle props. For jrefactory,
> there is only one.)
> */
>
> SourceProperty sp = (SourceProperty) i.next();
>
> Properties c = sp.getProperties("checkstyle");
> Properties j = sp.getProperties("jrefactory");
>
> setAntProperties(c);
> setAntProperties(j);
> }
> }
>
> /*
> This actually sets the Ant properties so they can be used in the
> build files, specifically, so the two Ant tasks above will work.
> */
> private setAntProperties(Properties props)
> {
> Set keys = props.ketSet();
> Iterator i = keys.iterator();
> while (i.hasNext())
> {
> String key = (String) i.next();
> getProject().setProperty(key, props.get(key));
> }
> }
> }
>
> I hope this makes sense. The great thing about this, is that it still
> allows users to manually override checkstyle or jrefactory individually
> OR they can just use the boiled down properties that you come up with.
>
> I hope this makes sense. This is the "maven" way that things are done
> with regards to properties and how to override. I hope it fits nicely
> into what you were planning.
>
> Let me know if you have nay questions,
>
> Thanks
> Pete
>
>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
