maven-m2-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Trygve Laugstøl <tryg...@inamo.no>
Subject Re: Proposal for changes in the mojo interface
Date Wed, 11 Aug 2004 15:14:19 GMT
On Wed, Aug 11, 2004 at 10:58:32AM +0200, Maczka Michal wrote:
> 
> 
> > -----Original Message-----
> > From: Trygve Laugstøl [mailto:trygvis@inamo.no]
> > Sent: Wednesday, August 11, 2004 5:27 AM
> > To: m2-dev@maven.apache.org
> > Subject: 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.
> > 
> 
> [...]
> > 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?
> 
> Hey!
> 
> 
> Wasn't the whole design reflecting the fact that most of the MOJOs 
> should not depend on MavenProject object?
> 
> Now this 
> 
> /**
>   * @parameter project <description>
>   *   required="true"
>   *   validator=""
>   *   expression="#project"
>   */
>  execute( MavenProject project );

Ok, the example might not have been the best. The compiler plugin would
look like this:

CompilationExecutionResponse execute( 
        String sourceDirectory, 
        String outputDirectory, 
        String[] classpathElements )

> 
> 
> not only removes the common interface method: 
> 
> void execute( PluginExecutionRequest request, PluginExecutionResponse
> response )
> 
> but mandates passing MavenProject object to plugins. 
> I don't know if this was badly chosen example or something which you want to
> see as normal practice.

The generated wrapper will implement the Plugin interface so for mavens
sake nothing will change.

> 
> Aren't neraly 100% of parameters which are needed by plugins accessible via
> MavenProject object?
> If you really want to pass MavenProject as parameter - why would you ever
> need other parameters?
> Only thing which you wmight need in addition to MavenProject are Plexus
> components..
> We have other, better ways of injecting components to components.
> 
> 
> 
> 
> IMO something like this will be sufficient for your plan:
> 
> 
> 
> class MyMojo implements MavenPlugin
> {
>    void execute( PluginExecutionRequest request, PluginExecutionResponse
> response )
>    {
>           
>            Foo foo = (Foo) request.getParam( "xxx" );
> 
>            Baa baa = (Baa) request.getParam( "yyy" );   
> 
>            execute( foo, baa );
>    }
> 
>   void execute( Foo foo, Baa baa )  
>   {
>      ..
>   }
> 
> 
> }
> 
> But this is not enough.
> 
> 
> The very first thing which is important here is a contract for "generating
> response".
> That is in fact the only tricky part here. We can indeed implement
> "requests" using dozen
> different ways - but with response things look differently. 
> 
> 
> Can you explain me how we should log, report error etc in case of such
> methods:
> 
> PluginExecutionReturnValue execute( MavenProject project );
> 
> (Just to remind your own note:
>    "* Reusability - It's supposed to be easy to resuse a mojo in any
> enviroment."
> )
> 
> 
> IMO PluginExecutionResponse must be given from outside in order to have a
> possibility of controlling the output. 
> 

The generated wrapper will get the PluginExecutionResponse as always. The
generated wrapper method would look like this:

void execute( PluginExecutionRequest request, 
              PluginExecutionResponse response )
{
    String sourceDirectory = 
        (String) request.getParameter( "sourceDirectory" );

    String outputDirectory = 
        (String) request.getParameter( "outputDirectory" );

    String[] classpathElements = 
        (String[]) request.getParameter( "classpathElements" );

    PluginExecutionReturnValue returnValue;

    try
    {
        returnValue = validateAndExecute( sourceDirectory,
                                          outputDirectory,
                                          classpathElements );
        response.setReturnValue( returnValue );
    }
    catch( Exception ex )
    {
        response.setExecutionError( ex );
    }
}

Note that a executing can have three results:

 * Ok - Everying is happy (all files compiled successfully)
 * Failure - Something wasn't right (a file didn't compile)
 * Error - Internal error (the mojo threw a exception)

The mojo will decide if the execution was ok or a failure.

The PluginExecutionReturnValue interface would be like the
CompilationFailureReponse:

public interface PluginExecutionReturnValue
{
    boolean isSuccess();
    String getShortMessage();
    String getLongMessage();
}

The CompilationExecutionReturnValue value would add a method to get all
the compilation errors:

 CompilationError[] getCompilationErrors;

There is still a couple of questions remaning like how can maven collect
results from all executions, but that would probably be best solved by
trying to implement this.

--
Trygve

> 
> 
> 
> 
> Michal
> 
> 
> 
> 
> 
> 
> 

Mime
View raw message