On 21 Sep 2005, at 09:26, Ashley Williams wrote:
Hi Chris,
I've mislaid the link to your plugin - can you post it up again??
On 20 Sep 2005, at 21:55, Chris Berry wrote:
Yes, it is the equivalent. But one thing confuses me, it's not about
executing a java process (per se) -- it's about executing Ant. And
it's not about maintenance. I think the heart of the discussion is
reuse. Not reinventing what Ant already does. Providing a mechanism
for reuse and versioning of Ant scripts. Reusing Ant scripts (or
pieces of them) from existing builds, when converting to Maven.
To the plugin developer, they can simply build an Ant script as they
always do, and a simple Mojo that passes parameters (and defaults)
from the POM in to the Ant script and executes it. Obviously, I could
have done it all within the Mojo myself, or I could have called Ant
programmatically, or I could just script the Ant. There are many ways
to get there.
To the plugin user, they don't know which technique is in use, and
shouldn't care...
On 9/20/05, Wendell Beckwith <[EMAIL PROTECTED]> wrote:
Just for clarification are you suggesting that a plugin that
needs to
execute a java process should be designed as an ant script, and
the plugin
would simply pass parameters to the ant script? I ask because I
don't see
how this is less maintenance than my current plugin that provides
intelligent defaults in the mojo and just needs to pass theses
parameters
along with any the user changed to the java process. Whenever
there are
plugin changes, I still go to the mojo in my design or an ant
script in your
design, correct?
Wb
On 9/20/05, John Casey <[EMAIL PROTECTED]> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I've actually done something just like this in the past, in
order to
call a Make-based build. IMO, you want to wrap a command line
call in a
plugin, to formalize the parameters - required and optional - which
constitutes a valid invocation of that executable. Otherwise,
it's prone
to breaking, misuse, and cut-and-paste maintenance style. In
short, it
isn't robust, and doesn't scale well. Anything where execution
logic is
embedded in the POM will suffer from this, IMO - including the
antrun
and execute plugins in the mojos project. A better solution for Ant
would be to build the plugin around the Ant script/scriptlet,
and bundle
that script into the plugin jar...then parameterize the input
configuration. Then, the script can climb the maturity curve,
and is
truly reused with a single point of maintenance.
- -john
Vincent Massol wrote:
|
|>-----Original Message-----
|>From: Wendell Beckwith [mailto:[EMAIL PROTECTED]
|>Sent: mardi 20 septembre 2005 19:15
|>To: Maven Users List
|>Subject: Re: [m2] reasons for sticking with maven
|>
|>John is basically stating the very thing that I'm against in the
statement
|>below. I have a 3rd party command line utility from
|>www.agitar.com <http://www.agitar.com><http://www.agitar.com>,
|>that basically does unit tests against our code. I want to
write (and
have
|>started writing) an M2 plugin to execute the java command line
for the
|>agitation process from my plugin. All I need now to complete
my plugin
|>besides more hours in a day is a plugin that will allow me to
execute a
|>java
|>command line. Now my plugin will integrate with the maven
lifecycle
during
|>the test phase. However, first I'm told to use the maven-
execute-plugin
|>and
|>then another dev states that it's bad and wants to see it
eliminated,
I'm
|>left thinking WTF!? This *helps* me adopt maven and the
process, not
|>hinders
|>it. My whole purpose for writing the plugin was so that I
could make the
|>plugin once and the other groups here and else where since I
would open
|>source it would be able to reuse it. Is this not what maven is
for?
|
|
| Just to muddy the waters: why don't you use commons-exec from
your
plugin's
| java code to execute your process?
|
| [snip]
|
| Thanks
| -Vincent
|
|
|
-------------------------------------------------------------------
--
| To unsubscribe, e-mail: [EMAIL PROTECTED]
| For additional commands, e-mail: [EMAIL PROTECTED]
|
|
|
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
iD8DBQFDMEdFK3h2CZwO/4URAjLaAKCo3sOGgRHJYg0nTR66E38EUaxN9wCfRY9m
3JIbhwsALTmuwn5OB/7gG9k=
=WOfH
-----END PGP SIGNATURE-----
-------------------------------------------------------------------
--
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]
---------------------------------------------------------------------
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]
