[m2] new xdoclet plugin + framework - feedback?

[Ashley Williams <ag...@mac.com>]

Hi

Just testing the waters here with regards to a new plugin framework  
that I've started, to see if there is any demand.
It's not specific to xdoclet but because I rely on xdoclet  
functionality a lot, it's become my prototype project.

First of all the link: https://svn.codehaus.org/mojo/trunk/mojo/mojo- 
sandbox/xjc-maven-plugin/earlyaccess/
There are 2 plugins under there called ejbdoclet and webdoclet (build  
mant first though).

There is also a sample ear project so that you can see how to invoke  
them.

Description
----------------

The motivation for this is that I would like to avoid reinventing the  
wheel when there is already an ant task out there.
Kenneys antrun plugin (that I believe the existing xdoclet delegates  
to) is a good solution to this.

For me the final piece of the jigsaw is a way of automatically  
specifying ant attributes that I feel maven should already
know about on my behalf. To take an example instead of specifying the  
following:


               <task><![CDATA[
                 <ejbdoclet ejbspec="2.1">
                   <fileset includes="**/*Bean.java"/>
                   <deploymentdescriptor/>
                   <remoteinterface/>
                   <homeinterface/>
                   <localinterface/>
                   <localhomeinterface/>
                   <session/>
                   <entitycmp/>
                   <entitypk/>
                   <jboss version="4.0"/>
                 </ejbdoclet>
               ]]></task>

So as you can see there are no attributes such as  
destDir="target/...........".
That's it really.

Implementation
---------------------
If anyone is interested it's quite easy to knock out plugins as it  
basically just defines a map. For example here is the webdoclet plugin:

    public void execute()
         throws MojoExecutionException, MojoFailureException
     {
         String[] mappings = new String[] {
             "@destDir",                      MantGoal.JAVA_GEN,
             "deploymentdescriptor/@destDir", MantGoal.META_INF_GEN,
             "fileset/@dir",                  MantGoal.JAVA,
             "jboss/@destDir",                MantGoal.META_INF_GEN
         };
         MantGoal goal = new MantGoal(this, project,  
"xdoclet.modules.ejb.EjbDocletTask", task, mappings);
         goal.execute("xdoclet.class.path");
     }

As you can see all I do is map an xpath location of the ant tag to a  
maven constant - eg JAVA_GEN is a generated-sources dir
under target. To give another example this is from xjc:

     public void execute()
         throws MojoExecutionException, MojoFailureException
     {
         String[] mappings = new String[] { "@target",  
MantGoal.JAVA_GEN };
         MantGoal goal = new MantGoal(this, project,  
"org.apache.ws.jaxme.generator.XJCTask", task, mappings);
         goal.execute();
     }

and that's it.

Considerations
--------------------
I suppose speed is the main thing - the fact that I have to maintain  
an additional layer to prop up ant can't be doing
me any favors. Not done any tests but this may be a problem for large  
builds. However to take the xjc plugin as
an example (I happen to be the maintainer) it would save me lots of  
time and unit tests to know I can just delegate
to ant.

Is this idea a non starter? Maybe there is howler of a design flaw  
that means this won't work long term - just tell
me before I spend too much time on it ;)

All opinions welcome.

Thanks
- Ashley



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