David Jackman wrote:
Here's another situation where I want to have a plugin call another plugin.
Can you tell me the "right" way to accomplish this?
In our group we have a release procedure that involves a few more steps
beyond running the release:prepare mojo. In fact, some of the parameters
into the release:prepare mojo are based on internal standards, so they could
be computed automatically.
I want to create a single plugin that embodies this entire release process that
also calls the release:prepare mojo with the correct parameters as part of that process.
This would be another situation where one plugin invokes another plugin.
Obviously there is coupling there. What is a better way to achieve this without that
coupling (is it even possible)? Would I create a lifecycle within my mojo that
puts
the necessary data on the bus and invokes the release:prepare mojo as part of
that lifecycle (thinking in Maven 2.1 terms)?
This is the wrong approach - you don't want to wrap the release plugin, but
extend it.
You could take a look at the release project (
https://svn.apache.org/repos/asf/maven/release/trunk ).
The release-manager works with an internal 'lifecycle' of it's own, with phases
etc.
I'm sure there's a place there where you can attach a component of your own
that does the preparation you need.
When you found the spot to hook in your functionality, you create a new project
in your corp SCM,
that has a dependency on release-manager. It declares a components.xml with
your component(s) listed,
in such a way that the release-manager picks them up and attaches them to the
proper phase.
Take a look at
release/maven-release-manager/src/main/resources/META-INF/plexus/components.xml).
The first component
declares the phases, the other components implement these phases.
Your component declaration in your components.xml would look something like
this:
<component>
<role>org.apache.maven.shared.release.phase.PreparePhase</role>
<role-hint>input-variables</role-hint>
<implementation>com.yourcompany.maven.release.phase.CustomPreparePhase</implementation>
</component>
and your CustomPreparePhase class would implement PreparePhase.
then you package this project up, and in your company root pom you declare a
pluginManagement section
for the release plugin, listing a dependency on your project containing the
above, like so:
<pluginManagement>
<plugins>
<plugin>
<artifactId>maven-release-plugin</...
<dependencies>
<dependency>
<groupId>com.yourcompany.maven
<artifactId>your-extension</artifactId>
<version.....
then whenever you do a release:prepare, your component will be injected into
the release manager
and be executed.
That's imho the proper approach.
-- Kenney
..David..
-----Original Message-----
From: Kenney Westerhof [mailto:[EMAIL PROTECTED]
Sent: Wednesday, June 06, 2007 5:48 PM
To: Maven Users List
Subject: Re: calling plugin in another plugin?
Nunn, Gerald wrote:
Jason,
It's a bad practice, and leads to coupling between plugins which is
bad. We've seen the aftermath of this happening in Maven 1.x.
Since I'm doing this already I'm curious how this could be done better and accomplish my goal, I'm a relative newbie to Mojos so I'm wondering if I am missing a better approach.
In my case, I needed a plugin that can handle a WebLogic shared library. A
shared library is a WAR or EAR that contains many different assets including
JARs and in order to be able to use these in Maven I've created a plugin that
temporarily unpacks the shared library and installs each JAR individually under
a library group name. It also creates a parent POM for the library that can be
used to drag in all the dependencies defined by the library.
In order to do this, my plugin needs to install each file individually. Rather
then rewrite the install plugin, I simply use my invoker class to invoke the
install plugin for each file I have unpacked passing in the necessary
parameters to make this work.
How could I accomplish the same goal using the approach you outlined?
This is a one-time setup, and really not part of the build.
You should have had those jars in the ears/wars in a repository already.
Either create a shellscript for it, or a pom, declaring a dependency on the
war/ear (i assume that one _is_
in a repository? if not - it shouldn't be part of the maven build lifecycle).
You use the maven-dependency-plugin to unpack the war/ear (for instance in
generate-resources), say to
${project.build.directory}/foo/
and specify a series of executions of the install plugin (for instance in
process-resources), each one configured
with the location a jar in ${project.build.directory}/foo/.
Anyway, this is not recommended practice, but I can see why your plugin is
useful.
The eclipse plugin has a similar mojo, that scans an eclipse installation
directory for plugins
and installs each plugin as a maven2 artifact in the local directory. It
doesn't use
the install mojo, afaik, but the maven api's.
I'm assuming your plugin is similar, in that it can unpack/install wars/ears
found in a bea weblogic installation
directory?
-- Kenney
Thanks,
Gerald
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
