-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I was actually referring to a couple of implementation patterns.
1. Wrap a command-line invocation. ~ Using commons-exec or any other Runtime.exec() wrapper, you can build a mojo that will pull in parameters from the Maven build process, format the command line, and execute...hopefully with output/error handling for that specific command. 2. Provide a plugin wrapper for an Ant script. ~ Using a given Ant script, bundle that script into a maven plugin whose functionality is centered on that single script. Again, maven provides the parameters from the build process, and passes them to the script/target in that plugin's embedded Ant script. Again, output/errors are handled in a way that is tuned to the task at hand. It's important to understand the specificity of these solutions. If you're using a general directly-embedded-Ant-inside-the-POM solution, you cannot handle output or errors in an intelligent manner. Same with a command-line-inside-the-POM solution. Moreover, in each of these inline solutions, your specific command-line or Ant invocation is confined to that POM and possibly its descendents, via inheritance. You cannot reuse this configuration outside the POM without incurring the costs of maintenance associated with cut-and-paste programming of any kind (i.e. multiple maintenance points, propagation of erroneous code, etc.). I'm not familiar with the plugin you've written, but I think the above statements apply generally. If you're already following those principles, I'd like to see what you have. I've been heads-down lately, so I may have missed the thread in which you were talking about it... Of course, using (or abusing) the maven plugin framework, you can do almost anything. Just don't ask me to maintain it or support it... :) Cheers, john Wendell Beckwith 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: | | 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] | | | | | | - --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFDME03K3h2CZwO/4URAhpLAKCF8cAMIq3yB7kFag2+Ux7EcKt2IgCdFLqX gF7ejHUha8PofCo/AKsDPYQ= =1Rse -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
