張旭 wrote:
Thanks to everyone.
Now I know there is no way through maven2 api to call another plugin. Am I
right?
No, but for your sake, let's say yes. ;)
According to Jason, it's a bad idea to call one plugin directly in another.
Also according to any other maven developer. It's totally against the
principals of maven.
But I still think it's maybe very convenience to do things like that so I
can use functions of other plugin directly and have parameters passed to
other plugin totally under my control.
If you do this kind of things in a plugin, the POM is no longer descriptive of
the process.
Your plugin would have an influence on the build, which could change the build.
For instance,
your plugin could add a dependency depending on the current time (bad example
but it illustrates the problem).
In this case, the build is no longer repeatable, which is bad.
As to using functions of plugins directly: that's not recommended.
Plugins/Mojos should be thin wrappers around a library. You'd want to use the
library directly.
The mojo's not only make those libraries available to your build, but also hook
them in in a precise way.
And you don't want to control parameters of other plugins - the POM author
should control those.
In maven 2.1 there is a shared-context component that can be used by plugins to
communicate data
to eachother, but it will not allow you to call plugins.
The only API you are allowed to use if you should depend on another plugin
would be the Mojo api: execute().
You can never count on any 3rd party library (the plugin's dependency) being
there, as the Mojo is
a facade or front-end for those libraries. And you should not depend on another
plugin and call it,
because you cannot configure it properly - this is dealt with in maven core.
Consider this the same limitation as Ant poses. You don't want the 'mkdir' task to have any
influence on the 'javac' task. The only communication between these two is through the configuration
of those tasks. In ant, there are no 2 tasks that call eachother. Maven mojo's
are comparable with ant tasks,
though more goal oriented, and no maven mojo will call another mojo directly.
Whatever you're trying to accomplish, there's a better, Maven-way, to do it.
-- Kenney
On 6/7/07, David Jackman <[EMAIL PROTECTED]> 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.1terms)?
..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]
