maven-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From denn...@apache.org
Subject svn commit: r1050317 - /maven/site/trunk/src/site/apt/guides/plugin/guide-ant-plugin-development.apt
Date Fri, 17 Dec 2010 08:45:40 GMT
Author: dennisl
Date: Fri Dec 17 08:45:40 2010
New Revision: 1050317

URL: http://svn.apache.org/viewvc?rev=1050317&view=rev
Log:
Fix typos and add some formating.

Modified:
    maven/site/trunk/src/site/apt/guides/plugin/guide-ant-plugin-development.apt

Modified: maven/site/trunk/src/site/apt/guides/plugin/guide-ant-plugin-development.apt
URL: http://svn.apache.org/viewvc/maven/site/trunk/src/site/apt/guides/plugin/guide-ant-plugin-development.apt?rev=1050317&r1=1050316&r2=1050317&view=diff
==============================================================================
--- maven/site/trunk/src/site/apt/guides/plugin/guide-ant-plugin-development.apt (original)
+++ maven/site/trunk/src/site/apt/guides/plugin/guide-ant-plugin-development.apt Fri Dec 17
08:45:40 2010
@@ -2,8 +2,9 @@
  Guide to Developing Ant Plugins
  ---
  John Casey
+ Dennis Lundberg
  -----
- 09 January 2006
+ 2010-12-17
  -----
 
 ~~ Licensed to the Apache Software Foundation (ASF) under one
@@ -31,7 +32,7 @@
 
 Developing Ant Plugins for Maven 2.x
 
-*WARNING
+*Warning
 
   <<The documentation below assumes that you have updated your locally cached
   cached copy of the maven-plugin-plugin. To update your copy, you will need to
@@ -58,7 +59,7 @@ mvn -U clean install
   
   As of the 2.0.1 release, Maven supports Ant-driven plugins. These plugins
   allow the invocation of Ant targets (specified in scripts embedded in the
-  plugin jar) at specific points in the build lifecycle. They can also inject
+  plugin JAR) at specific points in the build lifecycle. They can also inject
   parameter values into the Ant project instances when a target is called.
   
 *Conventions
@@ -352,24 +353,24 @@ hello.mojos.xml:
 
   You'll notice several differences from the old version of the mapping document.
   First, we've added <<requiresProject="true">> to the mojo declaration. This
tells
-  Maven that our mojo requires a valid project before it can execute...in our case, 
+  Maven that our mojo requires a valid project before it can execute. In our case, 
   we need a project so we can determine the correct <<projectName>> to use. Next,
   we've added two parameter declarations to our mojo mapping; one for <<name>>
and
   another for <<projectName>>.
   
-  The <<name>> parameter declaration provides an expression attribute...this
+  The <<name>> parameter declaration provides an expression attribute. This
   allows the user to specify <<<-Dname=somename>>> on the command line.
Otherwise,
   the only way to configure this parameter would be through a <<<\<configuration/\>>>>
   element within the plugin specification in the user's POM. Note that this
   parameter is required to have a value before our mojo can execute.
   
   The <<projectName>> parameter declaration provides two other interesting items.
-  First, it specifies a defaultValue attribute, which specifies an expression to
+  First, it specifies a <<<defaultValue>>> attribute, which specifies an
expression to
   be evaluated against Maven's current build state in order to extract the parameter's
-  value. Second, it specifies a readonly attribute, which means the user cannot
+  value. Second, it specifies a <<<readonly>>> attribute, which means the
user cannot
   directly configure this parameter - either via command line or configuration
   within the POM. It can only be modified by modifying the build state referenced
-  in the defaultValue...in our case, the name element of the POM. Also note that
+  in the <<<defaultValue>>>. In our case, the name element of the POM.
Also note that
   this parameter is declared to be required before our mojo can execute.
 
 **Rebuild It and Run It
@@ -408,8 +409,8 @@ mvn -Dname=John hello:hello
   If you're familiar with Ant, you're probably familiar with the common usage
   pattern of defining multiple build types within a single build script. For
   instance, you might have a build type for cleaning the project, another for
-  producing the application jar file, and yet another for producing the full
-  distribution including javadocs, etc.
+  producing the application JAR file, and yet another for producing the full
+  distribution including Javadocs, etc.
   
   The concept is pretty simple. Discrete chunks of the build process are separated
   into targets within the script. These targets can reference one another in
@@ -448,8 +449,7 @@ one-two.build.xml:
 
 **Map the Mojos
 
-  Next, we'll modify our original mapping document to map these two new mojos
-  instead of the old one:
+  Next, we'll add new mapping document to map these two new mojos:
   
 +---+
 one-two.mojos.xml:
@@ -557,7 +557,7 @@ test-project/pom.xml:
       <plugin>
         <groupId>org.myproject.plugins</groupId>
         <artifactId>hello-plugin</artifactId>
-        <version>1.0</version>
+        <version>1.0-SNAPSHOT</version>
         
         <configuration>
           <name>John</name>
@@ -597,13 +597,13 @@ mvn validate
 
   It's worth mentioning that Ant-driven plugins can just as easily contain
   multiple Ant build scripts. Simply follow the naming rules - naming each
-  A.build.xml, B.build.xml, C.build.xml, etc. for example - and be sure to
+  <<<A.build.xml>>>, <<<B.build.xml>>>, <<<C.build.xml>>>,
etc. for example - and be sure to
   provide a mapping document to correspond to each build script that contains
   a mojo (other build scripts may be contained in the plugin, and referenced 
   by one of these; they don't need mapping documents). So, for the above examples
-  (assuming they all contained mojo targets), you'd need: A.mojos.xml, B.mojos.xml,
-  and C.mojos.xml. If C.build.xml was referenced by A and B, but didn't contain
-  mojo targets, then you don't need a C.mojos.xml for obvious reasons.
+  (assuming they all contained mojo targets), you'd need: <<<A.mojos.xml>>>,
<<<B.mojos.xml>>>,
+  and <<<C.mojos.xml>>>. If <<<C.build.xml>>> was referenced
by A and B, but didn't contain
+  mojo targets, then you don't need a <<<C.mojos.xml>>> for obvious reasons.
 
 *Advanced Usage
 



Mime
View raw message