You are viewing a plain text version of this content. The canonical link for it is here.
Posted to m2-dev@maven.apache.org by Trygve Laugstøl <tr...@inamo.no> on 2004/08/11 05:26:45 UTC

Proposal for changes in the mojo interface

Hi

Jason and I have been thinking about the interfaces for the mojos, both
from the executor's side (maven or your favorite IDE) and the implementors
side.

Currently the only way to invoke a mojo is through the execute method:

 void execute( PluginExecutionRequest request,
               PluginExecutionResponse response )

All the parameters thats required to be in the request is stated through
javadoc tags in the class comment.

The mojo interface has to main goals:

 * Reusability - It's supposed to be easy to resuse a mojo in any
                 enviroment.
 * Versability - The mojo interfaces should be good enough for all
                 overseable future.

As we're getting used to making mojos, we're also discovering that this
interface isn't to easy to test nor is it particular typesafe.

So what I'm proposing is trying address these issues through:

 * Type safe execute() methods. The parameter declaration and validator is
   specified through javadoc parameter tags.
 * A single return type object. Each execute() method will have a return
   value that inherits PluginExecutionReturnValue.
 * Generated wrappers that exposed the interface thats exposed today. The
   wrappers will take care of validating the parameters accoring to the
   stated rules in the parameter javadocs.

The pros:
 * It's easier to test the plugin through the single method.
 * It's easier to use a single mojo as it has a type safe interface. It's
   possible to generate a type safe method that does the actual validation.
 * Maven can assume that the mojo will take care of itself and really
   doesn't need the type and validation information.

The cons:
 * The mojo generator needs to be changed a bit.
 * Each mojo will be executed through a generated wrapper as maven (and
   any other generic system using multiple mojos) will use.
 * Each mojo should probably have a validating type safe method too.
 * As there really isn't a single entry point for mojos anymore we can
   only standardize the naming to execute( ... ).

As a example of how the method will look I give you the rewamped eclipse
plugin interface:

 /**
  * @parameter project <description>
  *   required="true"
  *   validator=""
  *   expression="#project"
  */
 execute( MavenProject project );

Based on this it's possible to:

 * Generate a subclass that implements the Plugin interface. The generated
   method should be declared final.
 * A validating execute method can be generated. The signature would be
   something like:
     validateAndExecute( MavenProject project );

So, what do you all feel? Is it good? bad? Anything else you would like to
see addressed if we start refactoring the mojo interface and the mojos we
have?

--
Trygve