You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Ashley Williams <ag...@mac.com> on 2005/09/21 10:26:20 UTC

Re: [m2] Antfile plugin

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 <wb...@gmail.com> 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 <jd...@commonjava.org> 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:wbeckwith@gmail.com]
>>> |>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: users-unsubscribe@maven.apache.org
>>> | For additional commands, e-mail: users-help@maven.apache.org
>>> |
>>> |
>>> |
>>> -----BEGIN PGP SIGNATURE-----
>>> Version: GnuPG v1.2.6 (GNU/Linux)
>>>
>>> iD8DBQFDMEdFK3h2CZwO/4URAjLaAKCo3sOGgRHJYg0nTR66E38EUaxN9wCfRY9m
>>> 3JIbhwsALTmuwn5OB/7gG9k=
>>> =WOfH
>>> -----END PGP SIGNATURE-----
>>>
>>> -------------------------------------------------------------------- 
>>> -
>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: users-help@maven.apache.org
>>>
>>>
>>>
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org


Re: [m2] Antfile plugin

Posted by Chris Berry <ch...@gmail.com>.
This is it....
Cheers,
-- Chris

allows use of Ant build files
-----------------------------

        Key: MNG-897
        URL: http://jira.codehaus.org/browse/MNG-897
    Project: Maven 2
       Type: Improvement
 Components: maven-ant-plugin
   Versions: 2.0-alpha-3
 Reporter: Chris Berry
 Attachments: antfile.zip

Cheers,
-- Chris


On 9/21/05, Ashley Williams <ag...@mac.com> wrote:
>
> 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??
> >
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org


Re: [m2] Antfile plugin

Posted by Ashley Williams <ag...@mac.com>.
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 <wb...@gmail.com> 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 <jd...@commonjava.org> 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:wbeckwith@gmail.com]
>>>> |>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: users-unsubscribe@maven.apache.org
>>>> | For additional commands, e-mail: users-help@maven.apache.org
>>>> |
>>>> |
>>>> |
>>>> -----BEGIN PGP SIGNATURE-----
>>>> Version: GnuPG v1.2.6 (GNU/Linux)
>>>>
>>>> iD8DBQFDMEdFK3h2CZwO/4URAjLaAKCo3sOGgRHJYg0nTR66E38EUaxN9wCfRY9m
>>>> 3JIbhwsALTmuwn5OB/7gG9k=
>>>> =WOfH
>>>> -----END PGP SIGNATURE-----
>>>>
>>>> ------------------------------------------------------------------- 
>>>> --
>>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org