maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mansour <>
Subject Re: how to extend maven plugin
Date Thu, 18 Dec 2008 22:14:46 GMT
Stephen Connolly wrote:
> 2008/12/18 Luke Patterson <>
>> For most situations, you could consider the plugin artifact to be
>> prez-layer.  You are using the mojo injection mechanism and maven api
>> to gather input for the utility-artifact/wrapped-tool to process.
>> Is that consistent with what you were saying Stephen?
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:
> Sort of.
> The key point is that the plugin has the Mojo... the annotations will be
> injected into the Mojo... the Mojo's execute method then passes the
> parameters to the worker class... the worker classes *do not* extend
> AbstractMojo or any kind of Mojo.... if fact it's as if they don't know
> about Mojo at all... otherwise were back to the same problem again.
If we talk web development, you mean business logic by worker class, and
Mojo is just the class that extract the data from the plugin config
(pom) then passes these data to the business logic. Ok, I see now the
big picture. But then,
> Put the worker classes in a separate jar, leave the classes extending
> AbstractMojo in the plugin, and have the plugin depend on the worker classes
> jar.
Where does my new mojo fits ? If I separate the logic in a jar artifact
(which by the way the author of the docbkx did a great job on that) and 
leave the old  mojo, then where does the modification goes?  In a  new
mojo, in  the original one ?  in the pom  (set the default values) ?
> Examples of this pattern would be in some of the plugins (I suspect the
> enforcer and resources plugins would be good examples)
I am looking into this now , and
will check out the source soon.
> -Stephen

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message