defining goals that aggregate other maven goals

[Pete Aykroyd <ay...@gmail.com>]

Hi all,
I've been searching for any easy way to do this and haven't found one yet. I
want to create a plugin that handles the deployment details for our webapps
for integration testing. The actual how of deploying the webapps has been
completed already using a combination of the dependency, antrun, and cargo
plugins but we'll want to do this in a number of different projects that are
not necessarily in the same inheritance chain. So I'd like to extract this
functionality into a seperate plugin that will provide easily setup goals to
do it.

The easiest thing would be if I could just in the pom define a goal, but
that seems impossible. The alternative approach that I'm taking is writing a
java mojo that does the work. This is fine, except that  (for example) I
want to use the maven dependency plugin to do some of the work, but it's
been setup such that it's difficult to use programmatically. I can get
around it by subclassing the AbstractUnpackMojo and adding setters for the
necessary items, but the way it's designed makes me wonder if I'm missing a
very obvious way to do this. (no setter for project and the UnpackMojo is
declared final, so no direct subclassing).

I'd appreciate any ideas.

Regards,

Pete

Re: defining goals that aggregate other maven goals

[Pete Aykroyd <ay...@gmail.com>]

Nice. Thanks, Stuart.


On Dec 18, 2007 9:33 AM, Stuart McCulloch <st...@jayway.net>
wrote:

> On 19/12/2007, Pete Aykroyd <ay...@gmail.com> wrote:
> >
> > Yeah, I've been running into that... but wasn't aware that it was
> expected
> > behavior. Thanks for the heads up.
> > I've searched around and have found some earlier discussions where maven
> > developers made it clear that this was the way that maven was to be
> used.
> > I
> > can't figure out a way to make this kind of packaging of commands
> > convenient
> > in a maven way though. So I'm kind of stuck with this hacktastic
> solution
> > of
> > subclassing and manually injecting.
>
>
> FYI, I do have a tool that does some of the hacktastic work for you:
>
>
>
> http://www.ops4j.org/projects/pax/construct/maven-inherit-plugin/index.html
>
> HTH :)
>
> Regards,
> > Pete
> >
> > On Dec 17, 2007 8:50 PM, Stuart McCulloch <st...@jayway.net>
> > wrote:
> >
> > > On 15/12/2007, Pete Aykroyd <ay...@gmail.com> wrote:
> > > >
> > > > Hi all,
> > > > I've been searching for any easy way to do this and haven't found
> one
> > > yet.
> > > > I
> > > > want to create a plugin that handles the deployment details for our
> > > > webapps
> > > > for integration testing. The actual how of deploying the webapps has
> > > been
> > > > completed already using a combination of the dependency, antrun, and
> > > cargo
> > > > plugins but we'll want to do this in a number of different projects
> > that
> > > > are
> > > > not necessarily in the same inheritance chain. So I'd like to
> extract
> > > this
> > > > functionality into a seperate plugin that will provide easily setup
> > > goals
> > > > to
> > > > do it.
> > > >
> > > > The easiest thing would be if I could just in the pom define a goal,
> > but
> > > > that seems impossible. The alternative approach that I'm taking is
> > > writing
> > > > a
> > > > java mojo that does the work. This is fine, except that  (for
> example)
> > I
> > > > want to use the maven dependency plugin to do some of the work, but
> > it's
> > > > been setup such that it's difficult to use programmatically. I can
> get
> > > > around it by subclassing the AbstractUnpackMojo and adding setters
> for
> > > the
> > > > necessary items, but the way it's designed makes me wonder if I'm
> > > missing
> > > > a
> > > > very obvious way to do this. (no setter for project and the
> UnpackMojo
> > > is
> > > > declared final, so no direct subclassing).
> > >
> > >
> > > watch out for: http://jira.codehaus.org/browse/MNG-3042
> > >
> > > because when you subclass a mojo from another plugin project it's
> > > parameters
> > > and components won't be injected by the plexus container (basically
> > > because
> > > the
> > > XML descriptor for your plugin is generated from the _local_ source,
> and
> > > doesn't
> > > include the subclassed mojos)
> > >
> > > therefore a lot of the existing mojos don't expect to be extended and
> > are
> > > final...
> > >
> > > I'd appreciate any ideas.
> > > >
> > > > Regards,
> > > >
> > > > Pete
> > > >
> > >
> > >
> > >
> > > --
> > > Cheers, Stuart
> > >
> >
>
>
>
> --
> Cheers, Stuart
>

Re: defining goals that aggregate other maven goals

[Stuart McCulloch <st...@jayway.net>]

On 19/12/2007, Pete Aykroyd <ay...@gmail.com> wrote:
>
> Yeah, I've been running into that... but wasn't aware that it was expected
> behavior. Thanks for the heads up.
> I've searched around and have found some earlier discussions where maven
> developers made it clear that this was the way that maven was to be used.
> I
> can't figure out a way to make this kind of packaging of commands
> convenient
> in a maven way though. So I'm kind of stuck with this hacktastic solution
> of
> subclassing and manually injecting.


FYI, I do have a tool that does some of the hacktastic work for you:


http://www.ops4j.org/projects/pax/construct/maven-inherit-plugin/index.html

HTH :)

Regards,
> Pete
>
> On Dec 17, 2007 8:50 PM, Stuart McCulloch <st...@jayway.net>
> wrote:
>
> > On 15/12/2007, Pete Aykroyd <ay...@gmail.com> wrote:
> > >
> > > Hi all,
> > > I've been searching for any easy way to do this and haven't found one
> > yet.
> > > I
> > > want to create a plugin that handles the deployment details for our
> > > webapps
> > > for integration testing. The actual how of deploying the webapps has
> > been
> > > completed already using a combination of the dependency, antrun, and
> > cargo
> > > plugins but we'll want to do this in a number of different projects
> that
> > > are
> > > not necessarily in the same inheritance chain. So I'd like to extract
> > this
> > > functionality into a seperate plugin that will provide easily setup
> > goals
> > > to
> > > do it.
> > >
> > > The easiest thing would be if I could just in the pom define a goal,
> but
> > > that seems impossible. The alternative approach that I'm taking is
> > writing
> > > a
> > > java mojo that does the work. This is fine, except that  (for example)
> I
> > > want to use the maven dependency plugin to do some of the work, but
> it's
> > > been setup such that it's difficult to use programmatically. I can get
> > > around it by subclassing the AbstractUnpackMojo and adding setters for
> > the
> > > necessary items, but the way it's designed makes me wonder if I'm
> > missing
> > > a
> > > very obvious way to do this. (no setter for project and the UnpackMojo
> > is
> > > declared final, so no direct subclassing).
> >
> >
> > watch out for: http://jira.codehaus.org/browse/MNG-3042
> >
> > because when you subclass a mojo from another plugin project it's
> > parameters
> > and components won't be injected by the plexus container (basically
> > because
> > the
> > XML descriptor for your plugin is generated from the _local_ source, and
> > doesn't
> > include the subclassed mojos)
> >
> > therefore a lot of the existing mojos don't expect to be extended and
> are
> > final...
> >
> > I'd appreciate any ideas.
> > >
> > > Regards,
> > >
> > > Pete
> > >
> >
> >
> >
> > --
> > Cheers, Stuart
> >
>



-- 
Cheers, Stuart

RE: defining goals that aggregate other maven goals

["Brian E. Fox" <br...@reply.infinity.nu>]

It effectively means that every plugin needs to be a wrapper around
another shared module so that other things can use the code. It
certainly works, but is more overhead than should optimally be required.

-----Original Message-----
From: Pete Aykroyd [mailto:aykroyd@gmail.com] 
Sent: Tuesday, December 18, 2007 12:13 PM
To: Maven Developers List
Subject: Re: defining goals that aggregate other maven goals

Yeah, I've been running into that... but wasn't aware that it was
expected
behavior. Thanks for the heads up.
I've searched around and have found some earlier discussions where maven
developers made it clear that this was the way that maven was to be
used. I
can't figure out a way to make this kind of packaging of commands
convenient
in a maven way though. So I'm kind of stuck with this hacktastic
solution of
subclassing and manually injecting.

Regards,
Pete

On Dec 17, 2007 8:50 PM, Stuart McCulloch <st...@jayway.net>
wrote:

> On 15/12/2007, Pete Aykroyd <ay...@gmail.com> wrote:
> >
> > Hi all,
> > I've been searching for any easy way to do this and haven't found
one
> yet.
> > I
> > want to create a plugin that handles the deployment details for our
> > webapps
> > for integration testing. The actual how of deploying the webapps has
> been
> > completed already using a combination of the dependency, antrun, and
> cargo
> > plugins but we'll want to do this in a number of different projects
that
> > are
> > not necessarily in the same inheritance chain. So I'd like to
extract
> this
> > functionality into a seperate plugin that will provide easily setup
> goals
> > to
> > do it.
> >
> > The easiest thing would be if I could just in the pom define a goal,
but
> > that seems impossible. The alternative approach that I'm taking is
> writing
> > a
> > java mojo that does the work. This is fine, except that  (for
example) I
> > want to use the maven dependency plugin to do some of the work, but
it's
> > been setup such that it's difficult to use programmatically. I can
get
> > around it by subclassing the AbstractUnpackMojo and adding setters
for
> the
> > necessary items, but the way it's designed makes me wonder if I'm
> missing
> > a
> > very obvious way to do this. (no setter for project and the
UnpackMojo
> is
> > declared final, so no direct subclassing).
>
>
> watch out for: http://jira.codehaus.org/browse/MNG-3042
>
> because when you subclass a mojo from another plugin project it's
> parameters
> and components won't be injected by the plexus container (basically
> because
> the
> XML descriptor for your plugin is generated from the _local_ source,
and
> doesn't
> include the subclassed mojos)
>
> therefore a lot of the existing mojos don't expect to be extended and
are
> final...
>
> I'd appreciate any ideas.
> >
> > Regards,
> >
> > Pete
> >
>
>
>
> --
> Cheers, Stuart
>

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

Re: defining goals that aggregate other maven goals

[Pete Aykroyd <ay...@gmail.com>]

Yeah, I've been running into that... but wasn't aware that it was expected
behavior. Thanks for the heads up.
I've searched around and have found some earlier discussions where maven
developers made it clear that this was the way that maven was to be used. I
can't figure out a way to make this kind of packaging of commands convenient
in a maven way though. So I'm kind of stuck with this hacktastic solution of
subclassing and manually injecting.

Regards,
Pete

On Dec 17, 2007 8:50 PM, Stuart McCulloch <st...@jayway.net>
wrote:

> On 15/12/2007, Pete Aykroyd <ay...@gmail.com> wrote:
> >
> > Hi all,
> > I've been searching for any easy way to do this and haven't found one
> yet.
> > I
> > want to create a plugin that handles the deployment details for our
> > webapps
> > for integration testing. The actual how of deploying the webapps has
> been
> > completed already using a combination of the dependency, antrun, and
> cargo
> > plugins but we'll want to do this in a number of different projects that
> > are
> > not necessarily in the same inheritance chain. So I'd like to extract
> this
> > functionality into a seperate plugin that will provide easily setup
> goals
> > to
> > do it.
> >
> > The easiest thing would be if I could just in the pom define a goal, but
> > that seems impossible. The alternative approach that I'm taking is
> writing
> > a
> > java mojo that does the work. This is fine, except that  (for example) I
> > want to use the maven dependency plugin to do some of the work, but it's
> > been setup such that it's difficult to use programmatically. I can get
> > around it by subclassing the AbstractUnpackMojo and adding setters for
> the
> > necessary items, but the way it's designed makes me wonder if I'm
> missing
> > a
> > very obvious way to do this. (no setter for project and the UnpackMojo
> is
> > declared final, so no direct subclassing).
>
>
> watch out for: http://jira.codehaus.org/browse/MNG-3042
>
> because when you subclass a mojo from another plugin project it's
> parameters
> and components won't be injected by the plexus container (basically
> because
> the
> XML descriptor for your plugin is generated from the _local_ source, and
> doesn't
> include the subclassed mojos)
>
> therefore a lot of the existing mojos don't expect to be extended and are
> final...
>
> I'd appreciate any ideas.
> >
> > Regards,
> >
> > Pete
> >
>
>
>
> --
> Cheers, Stuart
>

Re: defining goals that aggregate other maven goals

[Stuart McCulloch <st...@jayway.net>]

On 15/12/2007, Pete Aykroyd <ay...@gmail.com> wrote:
>
> Hi all,
> I've been searching for any easy way to do this and haven't found one yet.
> I
> want to create a plugin that handles the deployment details for our
> webapps
> for integration testing. The actual how of deploying the webapps has been
> completed already using a combination of the dependency, antrun, and cargo
> plugins but we'll want to do this in a number of different projects that
> are
> not necessarily in the same inheritance chain. So I'd like to extract this
> functionality into a seperate plugin that will provide easily setup goals
> to
> do it.
>
> The easiest thing would be if I could just in the pom define a goal, but
> that seems impossible. The alternative approach that I'm taking is writing
> a
> java mojo that does the work. This is fine, except that  (for example) I
> want to use the maven dependency plugin to do some of the work, but it's
> been setup such that it's difficult to use programmatically. I can get
> around it by subclassing the AbstractUnpackMojo and adding setters for the
> necessary items, but the way it's designed makes me wonder if I'm missing
> a
> very obvious way to do this. (no setter for project and the UnpackMojo is
> declared final, so no direct subclassing).


watch out for: http://jira.codehaus.org/browse/MNG-3042

because when you subclass a mojo from another plugin project it's parameters
and components won't be injected by the plexus container (basically because
the
XML descriptor for your plugin is generated from the _local_ source, and
doesn't
include the subclassed mojos)

therefore a lot of the existing mojos don't expect to be extended and are
final...

I'd appreciate any ideas.
>
> Regards,
>
> Pete
>



-- 
Cheers, Stuart