Nice. Thanks, Stuart.
On Dec 18, 2007 9:33 AM, Stuart McCulloch <[EMAIL PROTECTED]> wrote: > On 19/12/2007, Pete Aykroyd <[EMAIL PROTECTED]> 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 <[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 > > > > > > > > > -- > Cheers, Stuart >
