You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by jv...@apache.org on 2005/09/10 13:55:33 UTC
svn commit: r279993 -
/maven/components/trunk/maven-core-it-plugin/src/main/java/org/apache/maven/plugin/coreit/CoreItMojoWithSetters.java
Author: jvanzyl
Date: Sat Sep 10 04:55:30 2005
New Revision: 279993
URL: http://svn.apache.org/viewcvs?rev=279993&view=rev
Log:
o adding a mojo that uses setters
Added:
maven/components/trunk/maven-core-it-plugin/src/main/java/org/apache/maven/plugin/coreit/CoreItMojoWithSetters.java
Added: maven/components/trunk/maven-core-it-plugin/src/main/java/org/apache/maven/plugin/coreit/CoreItMojoWithSetters.java
URL: http://svn.apache.org/viewcvs/maven/components/trunk/maven-core-it-plugin/src/main/java/org/apache/maven/plugin/coreit/CoreItMojoWithSetters.java?rev=279993&view=auto
==============================================================================
--- maven/components/trunk/maven-core-it-plugin/src/main/java/org/apache/maven/plugin/coreit/CoreItMojoWithSetters.java (added)
+++ maven/components/trunk/maven-core-it-plugin/src/main/java/org/apache/maven/plugin/coreit/CoreItMojoWithSetters.java Sat Sep 10 04:55:30 2005
@@ -0,0 +1,105 @@
+/*
+ * Copyright (c) 2005 Your Corporation. All Rights Reserved.
+ */
+package org.apache.maven.plugin.coreit;
+
+import org.apache.maven.plugin.AbstractMojo;
+import org.apache.maven.plugin.MojoExecutionException;
+
+import java.io.File;
+import java.io.FileWriter;
+import java.io.IOException;
+
+/**
+ * @goal setter-touch
+ *
+ * @description Goal which cleans the build
+ */
+public class CoreItMojoWithSetters
+ extends AbstractMojo
+{
+ /**
+ * @parameter
+ * property="outputDirectoryValue"
+ * expression="${project.build.directory}"
+ * @required
+ */
+ private String outputDirectoryValue;
+
+ /**
+ * @parameter property="foo"
+ */
+ private String fooValue;
+
+ /**
+ * @parameter property="bar"
+ */
+ private String barValue;
+
+ // ----------------------------------------------------------------------
+ // Setters
+ // ----------------------------------------------------------------------
+
+ public void setOutputDirectory( String outputDirectory )
+ {
+ this.outputDirectoryValue = outputDirectory;
+ }
+
+ public void setFoo( String fooValue )
+ {
+ this.fooValue = fooValue;
+ }
+
+ public void setBar( String barValue )
+ {
+ this.barValue = barValue;
+ }
+
+ // ----------------------------------------------------------------------
+ //
+ // ----------------------------------------------------------------------
+
+
+ public void execute()
+ throws MojoExecutionException
+ {
+ touch( new File( outputDirectoryValue ), "touch.txt" );
+
+ File outDir = new File( outputDirectoryValue );
+
+ // Test parameter setting
+ if ( fooValue != null )
+ {
+ touch( outDir, fooValue );
+ }
+
+ if ( barValue != null )
+ {
+ touch( outDir, barValue );
+ }
+ }
+
+ private static void touch( File dir, String file )
+ throws MojoExecutionException
+ {
+ try
+ {
+ if ( !dir.exists() )
+ {
+ dir.mkdirs();
+ }
+
+ File touch = new File( dir, file );
+
+ FileWriter w = new FileWriter( touch );
+
+ w.write( file );
+
+ w.close();
+ }
+ catch ( IOException e )
+ {
+ throw new MojoExecutionException( "Error touching file", e );
+ }
+ }
+}
---------------------------------------------------------------------
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
Posted by Jason van Zyl <ja...@maven.org>.
On Sun, 2005-09-11 at 10:16 +1000, Brett Porter wrote:
> Can you explain the reason for going with a property attribute and using
> methods that don't match the field name? This means that they don't work
> under bean conventions (and IDE generation of getters/setters :)
Probably should have just pulled from my stock pile of quotes:
"... this is the Uniform Access principle. Hiding the difference between
access to instance variables and calculated values shields users from
the implementation of your class ..."
-- Object Software Construction, Bertrand Meyer
Which is really what a property is. Even in the simplest example you
google for shows that even a simple field may not match up name wise and
it doesn't matter as tools will use the bean tools which look for
methods.
http://www.oreilly.com/catalog/javabeans/chapter/ch01.html
--
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
Posted by 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
Posted by 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
Re: svn commit: r279993 -
/maven/components/trunk/maven-core-it-plugin/src/main/java/org/apache/maven/plugin/coreit/CoreItMojoWithSetters.java
Posted by 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
Posted by Brett Porter <br...@apache.org>.
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? This means that they don't work
under bean conventions (and IDE generation of getters/setters :)
I would have expected a simple:
/** @parameter */
private String foo;
public void setFoo( String foo ) { this.foo = foo }
public String getFoo() { return foo; }
Cheers,
Brett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org