Tom Huybrechts wrote:
Extending existing mojo's doesn't work very well, because the parameters for the extended mojo are not injected.
Thanks, you confirmed my diagnosis. :)
Do you really need to subclass ? Can't you just write an additional mojo and bind that to the install phase, next to the ordinary install?
I was planning on adding the new Mojo to maven-bundle-plugin (in Felix), binding it to the install phase, and changing the default install phase to use maven-bundle-plugin. If the new Mojo subclassed InstallMojo from maven-install-plugin, it would have all the functionality of maven-install-plugin plus the functionality to create/update the OBR repository.xml file.
If I mangaed to get that working (and I was very ambitious), I would then add another Mojo to maven-bundle-plugin, bound to the deploy phase, that would deploy a bundle to a remote OBR, updating its repository.xml. Similarly, it would subclass DeployMojo from maven-deploy-plugin and add the functionality to create/update the remote repository.xml file.
When completed, bundle developers would get the appropriate default behavior for the package, install, and deploy phases by specifying <packaging>bundle</packaging> in their pom file.
Is there a better way? Can two bundles be bound to the same phase as default? If not, what exactly would I add to a pom.xml to run the new Mojo "next to the ordinary install"?
And when you have the OBR plugin, would you mind sharing it :) ? Tom
Yes, I was going to contribute the patch to Felix. Tim --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
