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:[EMAIL PROTECTED] 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 <[EMAIL PROTECTED]> wrote: > On 15/12/2007, Pete Aykroyd <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
