You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by nicolas de loof <ni...@apache.org> on 2008/04/05 21:01:15 UTC
[proposal] AbstractMojo enhancement
Hello,
Plugin developer only require to implement the Mojo interface, but in most
(all ?) the case they extend AbstractMojo.
Having myself created or contributed multiple plugins, I had to solve the
same issues many time, using an copy/paste.
Could we make the AbstractMojo class more usefull by providing some
commonly-used support methods ?
I myslef had many time to build a Classloader for the executed project to be
able to load project classes from a class processing tool. I've not created
a feature lits (yet) but just looking at Maven + Mojo plugins, we could
find many common requirements.
Nicolas.
Re: [proposal] AbstractMojo enhancement
Posted by Mark Hobson <ma...@gmail.com>.
+1, I've thought this numerous times in the past. This class may be
handy for the new component:
http://svn.codehaus.org/mojo/trunk/sandbox/apt-maven-plugin/src/main/java/org/codehaus/mojo/apt/LogUtils.java
Mark
On 05/04/2008, Jason van Zyl <ja...@maven.org> wrote:
>
> On 5-Apr-08, at 12:21 PM, Benjamin Bentmann wrote:
>
> >
> > > Could we make the AbstractMojo class more usefull by providing some
> > > commonly-used support methods ?
> > >
> >
> > +1 on the general idea to avoid copy&paste, -1 on the proposal to share
> code via AbstractMojo.
> >
> > For some reason, AbstractMojo is part of the uber JAR and as such updates
> to it would be bound to the current Maven version. Last but not least,
> prefering composition over inheritance is usually a better approach to share
> code among otherwise unrelated components.
> >
> > Having Plexus hanging around, it's seems natural to start up a component
> for this just like Vincent did with the maven-doxia-tools.
> >
> >
>
> Exactly. Composition with component.
>
>
> >
> > Benjamin
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder, Apache Maven
> jason at sonatype dot com
> ----------------------------------------------------------
>
> Selfish deeds are the shortest path to self destruction.
>
> -- The Seven Samuari, Akira Kirosawa
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [proposal] AbstractMojo enhancement
Posted by Jason van Zyl <ja...@maven.org>.
On 5-Apr-08, at 12:21 PM, Benjamin Bentmann wrote:
>> Could we make the AbstractMojo class more usefull by providing some
>> commonly-used support methods ?
>
> +1 on the general idea to avoid copy&paste, -1 on the proposal to
> share code via AbstractMojo.
>
> For some reason, AbstractMojo is part of the uber JAR and as such
> updates to it would be bound to the current Maven version. Last but
> not least, prefering composition over inheritance is usually a
> better approach to share code among otherwise unrelated components.
>
> Having Plexus hanging around, it's seems natural to start up a
> component for this just like Vincent did with the maven-doxia-tools.
>
Exactly. Composition with component.
>
> Benjamin
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
Selfish deeds are the shortest path to self destruction.
-- The Seven Samuari, Akira Kirosawa
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [proposal] AbstractMojo enhancement
Posted by Benjamin Bentmann <be...@udo.edu>.
> Could we make the AbstractMojo class more usefull by providing some
> commonly-used support methods ?
+1 on the general idea to avoid copy&paste, -1 on the proposal to share code
via AbstractMojo.
For some reason, AbstractMojo is part of the uber JAR and as such updates to
it would be bound to the current Maven version. Last but not least,
prefering composition over inheritance is usually a better approach to share
code among otherwise unrelated components.
Having Plexus hanging around, it's seems natural to start up a component for
this just like Vincent did with the maven-doxia-tools.
Benjamin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [proposal] AbstractMojo enhancement
Posted by Jason van Zyl <ja...@maven.org>.
I would use composition instead of inheritance and create helper
components for those things. Pushing all the helper methods, when in
most cases hardly any of them will be used, is not a good design.
We definitely need helps for making classloaders (take the one from
jetty run), working with include/excludes, operating on resources,
working with dependencies, and so on. This should not all go into the
AbstractMojo as it will also expose these things as APIs.
A set of components for helping with common tasks where people can
pick and choose what they like would be better.
On 5-Apr-08, at 12:01 PM, nicolas de loof wrote:
> Hello,
>
> Plugin developer only require to implement the Mojo interface, but
> in most
> (all ?) the case they extend AbstractMojo.
>
> Having myself created or contributed multiple plugins, I had to
> solve the
> same issues many time, using an copy/paste.
>
> Could we make the AbstractMojo class more usefull by providing some
> commonly-used support methods ?
>
> I myslef had many time to build a Classloader for the executed
> project to be
> able to load project classes from a class processing tool. I've not
> created
> a feature lits (yet) but just looking at Maven + Mojo plugins, we
> could
> find many common requirements.
>
> Nicolas.
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
We know what we are, but know not what we may be.
-- Shakespeare
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org