Re: svn commit: r279993 - /maven/components/trunk/maven-core-it-plugin/src/main/java/org/apache/maven/plugin/coreit/CoreItMojoWithSetters.java

[Jason van Zyl <ja...@maven.org>]

On Sun, 2005-09-11 at 10:16 +1000, Brett Porter wrote:
> jvanzyl@apache.org wrote:
> 
> >+    /**
> >+     * @parameter property="foo"
> >+     */
> >+    private String fooValue;
> >  
> >
> ...
> 
> >+    public void setFoo( String fooValue )
> >+    {
> >+        this.fooValue = fooValue;
> >+    }
> >  
> >
> Can you explain the reason for going with a property attribute and using
> methods that don't match the field name? 

Strictly speaking properties don't have to correspond to fields, they
may involve a calculation say. I was just trying to account for that
case even though in the case of mojos the field name will most likely
match the the read/write method name.

> This means that they don't work
> under bean conventions (and IDE generation of getters/setters :)

That's just a convenience where the IDE uses the field name as the basis
for the read/write methods. But you may very well have a property where
the corresponding read/write methods use no fields, or use multiple
field values, or mutate a field value.

> I would have expected a simple:
> 
> /** @parameter */
> private String foo;
> 
> public void setFoo( String foo ) { this.foo = foo }
> public String getFoo() { return foo; }

Again, just trying to account for the case where this does not hold. I
wanted to be explicit about the name of the property when it didn't
match up exactly with field names. But if any tooling were to be made
you would want to provide the property name and you couldn't correctly
in cases where it varied from the field name.

Easy enough to change to as in the case above Plexus will simply attempt
to use the setter first.

> Cheers,
> Brett
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
> 
> 
-- 
jvz.

Jason van Zyl
jason at maven.org
http://maven.apache.org

People develop abstractions by generalizing from concrete examples.
Every attempt to determine the correct abstraction on paper without
actually developing a running system is doomed to failure. No one
is that smart. A framework is a resuable design, so you develop it by
looking at the things it is supposed to be a design of. The more examples
you look at, the more general your framework will be.

  -- Ralph Johnson & Don Roberts, Patterns for Evolving Frameworks 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: svn commit: r279993 - /maven/components/trunk/maven-core-it-plugin/src/main/java/org/apache/maven/plugin/coreit/CoreItMojoWithSetters.java

[Jason van Zyl <ja...@maven.org>]

On Sun, 2005-09-11 at 12:52 +1000, Brett Porter wrote:

> So does this mean that it works without the property parameter? 

Only if the field name matches the name of the getter/setter methods. If
the property name is not specified then the setter will fail and the
private field will be used directly.

> If
> that's the case, then I'm fine with it and we can just use the default
> case with property as the field name. property can remain as an advanced
> use case. I still wonder how this could be made to be useful - attach
> the metadata to the getter instead perhaps (like in beanshell)?

That would probably make more sense, I just left it with the field for
the moment to get it to work.

> - Brett
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
> 
> 
-- 
jvz.

Jason van Zyl
jason at maven.org
http://maven.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: svn commit: r279993 - /maven/components/trunk/maven-core-it-plugin/src/main/java/org/apache/maven/plugin/coreit/CoreItMojoWithSetters.java

[Brett Porter <br...@apache.org>]

Jason van Zyl wrote:

>Strictly speaking properties don't have to correspond to fields, they
>may involve a calculation say. I was just trying to account for that
>case even though in the case of mojos the field name will most likely
>match the the read/write method name.
>  
>
Sorry, I don't get what you mean by this - do you have an example?

>>This means that they don't work
>>under bean conventions (and IDE generation of getters/setters :)
>>    
>>
>
>That's just a convenience where the IDE uses the field name as the basis
>for the read/write methods. 
>
Actually, I was thinking more along the line of how javabeans are
specified to work.

>But you may very well have a property where
>the corresponding read/write methods use no fields, or use multiple
>field values, or mutate a field value.
>  
>
How would you introduce a property that didn't have a field in the
current set up, or one that used multiple fields without just picking
one of those fields as the one with attached metadata?

You can definitely do calculations on one field in the getter/setter as
is - but this technique just seems like a way to give it a different
name than the field name, for which we already have "alias" for
configuration. I assume configuration maps to the setters, not the field
itself when present, so this is equivalent.

I'm only looking at this from the mojo perspecitve, but I'd prefer to
keep it simple.

>Easy enough to change to as in the case above Plexus will simply attempt
>to use the setter first.
>  
>
So does this mean that it works without the property parameter? If
that's the case, then I'm fine with it and we can just use the default
case with property as the field name. property can remain as an advanced
use case. I still wonder how this could be made to be useful - attach
the metadata to the getter instead perhaps (like in beanshell)?

- Brett

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org