On 2/18/07, Tim Moloney <[EMAIL PROTECTED]> wrote:
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?
Probably not - this looks like a perfect case for creating your own custom
type.
Can two bundles be bound to the same phase as
default?
Yes, you can write a comma-seperated list of goals in the phase field of
your packaging extension.
For example, the definition of the maven-plugin lifecycle mapping for phase
is:
<package>
org.apache.maven.plugins:maven-jar-plugin:jar,
org.apache.maven.plugins:maven-plugin-plugin:addPluginArtifactMetadata
</package>
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]
--
Eric Redmond
http://codehaus.org/~eredmond
