You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Chris Berry <ch...@gmail.com> on 2005/09/15 16:07:21 UTC
[m2] antfile plugin (was: "whether to use ant")
Greetings,
There was a recent thread on "whether to use ant". It is a long thread
(19+ posts) and became divergent. So rather than bury that post there,
I will raise it here to the top level. Like people in that thread, I
firmly believe that a happy marriage between Maven and Ant is in the
best interest of all.
When maven began it was really intended to be an easy way to share Ant
build scripts. We were all tired of reinventing the wheel. Every time
we started a new Ant project we had to copy in and customize a set of
Ant build scripts. With every new Ant project, we violated the Don't
Repeat Yourself" principle. Enhancements/bug fixes had to be hand
propagated across projects.
Over time, maven became more than this. It added Good Stuff like the
POM (a holistic "recipe" for the project) and dependency management.
It added Bad Stuff, like Jelly. That's all water under the bridge.
IMO, maven should emphatically refrain from reinventing the wheel. Ant
is the defacto Java build tool, although it is in no way limited to
Java. Ant already does ~90+% of the individual Tasks required by a
build system. And what it doesn't do is typically provided by others
wishing to either augment Ant's deficiencies (e.g. ant-contrib) or
wishing to have their tools adopted (e.g. axis-ant). Ant is
cross-platform, and is intended as a build tool -- not as a general
scripting language. Ant's original intent was simply to be a "better
make".
Maven should concentrate on being the "glue" that holds it all
together -- providing value in reusability, repeatability, and
holistic project management.
To this end, I have written an Antfile Plugin. It extends the AntRun
plugin, and simply allows you to delegate to an Ant buildfile. The
buildfile is rolled into the plugin jar, and then, is unzipped from
that jar into the /target and is run during the build.
One simply extends the AntFile plugin with their own plugin, declaring
the buildfile, pulling config info from the POM and passing them on as
properties to Ant. It's very simple to use.
(BTW: I have built an Axis plugin on top of this, validating it's usage pattern)
I passed my AntRun plugin to John Casey (one of the Maven gurus), and
I hope that The Powers That Be will allow it into the HEAD of the SVN
tree.
Cheers,
-- Chris
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: [m2] antfile plugin (was: "whether to use ant")
Posted by Chris Berry <ch...@gmail.com>.
On 9/15/05, Kenney Westerhof <ke...@apache.org> wrote:
> It's already working, I don't quite get what you mean? Why would
> you need java code to pass on the properties when they're already
> available?
The ant buildfile is expecting properties. These may or may not match
what is available locally. Somewhere we need to call
target.getProject().setUserProperty( "some.ant.property", myValue );
And then let them propagate w/ inheritall=true
Your AntPropertyHelper is not doing this, but maybe I'm missing something...
> Maybe we can merge your AntFile code to the AntRun plugin, so you
> can either specify nested ant script or refer to some buildfile.
That would be great!!
> M2 already does the chunk of the build.. why would you replicate with ant
> scripts what we've worked so hard for to do with maven itself? :)
You wouldn't -- if Maven could actually do everything -- but Maven is
not a universal tool. It cannot and will not ever do all that people
need in their builds. Sure it might hit 80-90% over time -- but there
will always be those chunks that require customization. All we are
talking about is making that piece easier.
> > So you might have an Ant-based build that you're converting to m2.
> > Let's assume that ~80% is directly convertible to m2, and there are,
> > say, 2 things that are specific to your needs-- at, say, 2 different
> > phases of the Ant build. These should be pulled into 2 m2 plugins that
> > you layer into the general m2 sequence.
>
> .. or just bind the AntRun plugin to these two phases and paste the
> snippets there. Saves you writing 2 plugins. And if you were writing 2
> plugins, why not make them native? Or run the AntTasks directly,
> without people having to specify some scriptlet code (or embedding
> scriptlet code in the plugin..)..?
I want to reuse them. Your suggested approach is not reusable.
>
> True, but the main idea is still: KISS! Say I want a deploy task,
> because Cargo doesn't have a container deploy plugin yet. I just need
> a <copy> tag, 1 line, very simple. It's meant for those things.
> If it gets bigger than a few lines and it's possible to re-use it,
> it should ofcourse go in a separate plugin. But then the question arrises:
> create an ant script and wrap a m2 plugin around that to configure the
> script, or just create a pure Mojo?
>
> But, ofcourse I see the benefits of this (else the antrun plugin
> probably wouldn't have existed), but I'm afraid if everybody can do it
> with ant, they won't take the time to write a great maven2 plugin that's
> far more reusable than a customized ant script.
Sorry Kenney, but I don't get it. As Ashley said, to the plugin user
there is no difference between the two approaches. But to the plugin
writer there certainly is.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: [m2] antfile plugin (was: "whether to use ant")
Posted by Chris Berry <ch...@gmail.com>.
On 9/15/05, Kenney Westerhof <ke...@apache.org> wrote:
> :) Well, I agree mostly, so far.
>
> So, it's back to Jelly, or, with m2, marmalade. I think an 'ant' scripting
> language is in the works, next to beanshell / marmalade / java, maybe
> that'll be the solution then. No mo task wrapping, just native ant
> plugins.
Jeez, I hope not. The last thing we need is another Jelly. ;-)
BTW: I'm not certain what you are referring to by 'ant scripting
language' ?? But today one can do most scripting that's required using
the ant-contrib tasks -- they fill the void nicely...
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: [m2] antfile plugin (was: "whether to use ant")
Posted by Mark Hobson <ma...@gmail.com>.
On 15/09/05, Kenney Westerhof <ke...@apache.org> wrote:
> Well, there's one 'problem': a tomcat plugin. Why would you want
> a tomcat plugin? Using tomcat is the choice of the person deploying
> it. It should just have a 'deployer' plugin that can handle more than just
> tomcat, and is configured using environment settings (settings.xml,
> profile.xml..). That's the problem with ant tasks: they're too fine
> grained and too specific. (which is also one of the good things, at least
> for ant).
Which in fact is exactly where the maven tomcat plugin code is heading
- into the cargo codebase. Once I get a moment to flesh out the cargo
m2 plugin I've got sitting here we'll be able to do this. Who said
rewriting ant tasks was pointless.. ;)
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: [m2] antfile plugin (was: "whether to use ant")
Posted by Kenney Westerhof <ke...@apache.org>.
On Thu, 15 Sep 2005, Ashley Williams wrote:
Hi Ashley,
> Hi Kenney,
>
> Don't know about you but I'm definitely getting bogged down by the
> details of the technology so I'm focused on the high level details
> here...
That's fine ;)
> There are an enormous number of ant tasked to be scrounged as Chris
> put it and IMHO it would be insane for maven to try to rewrite them.
> For one it would cost effort and two you would lose that comfort
> factor that people have from years of Ant experience.
True.
> I'm far from an expert in Maven. But I do know that if an ant task
> were wrapped inside a mojo then you wouldn't be able to tell the
> difference between it and any other mojo that didn't have any ant
> magic inside - apart from some really familiar looking ant syntax
> right there in the pom. Therefore I don't understand the comment that
> it can't be reused in the same way.
Well, ideally you wouldn't have to specify all the parameters to such
a task, since most of them are already available. Having the full
ant task to configure in the pom (even though the wrapping plugin can
fill in some) can lead to configuration errors.. but that can be overcome
by warnings etc.
> Related to this I see some ant tasks as very special. For example you
> might expect that an ant tomcat task embedded in your pom would
> already know where to find your deployable war file to save you
> configuring that particular property. Therefore the mojo (container?
> wrapper?decorator?bridge?) would know how to pass some of those maven
> properties to the corresponding ant properties perhaps by consulting
> a text file map.
Well, there's one 'problem': a tomcat plugin. Why would you want
a tomcat plugin? Using tomcat is the choice of the person deploying
it. It should just have a 'deployer' plugin that can handle more than just
tomcat, and is configured using environment settings (settings.xml,
profile.xml..). That's the problem with ant tasks: they're too fine
grained and too specific. (which is also one of the good things, at least
for ant).
> I've actually been talking about ant tasks, whereas I think Chris
> (correct me if I'm wrong) was talking about whole build.xml files. I
> don't see this as somehow replacing any of what Maven has to offer,
> it just offers another language for writing plugins in besides java.
> I mean how much more damage can I do in ant than I can do in Java ;)
:) Well, I agree mostly, so far.
So, it's back to Jelly, or, with m2, marmalade. I think an 'ant' scripting
language is in the works, next to beanshell / marmalade / java, maybe
that'll be the solution then. No mo task wrapping, just native ant
plugins.
> Sounds as if there might be some overlap between the two ant plugins
> discussed here - ant targets and whole build files - it would be
> interesting to see if they could combined.
Yeah, although the approach is different.. But they complete each other
nicely. Maybe the antFile plugin can become the 4th scripting language
available for plugins. But there's already discussion on that.
-- Kenney
> -AW
>
>
> On 15 Sep 2005, at 17:44, Kenney Westerhof wrote:
>
> > On Thu, 15 Sep 2005, Chris Berry wrote:
> >
> > Hi,
> >
> > Let me step in for a moment here... ;)
> >
> >
> >>> 1. I'm concerned that I have to write java code in order to call ant
> >>> tasks. For example to support the tomcat task, would I or somebody
> >>> else have to have extended the antfile plugin?
> >>>
> >>
> >> The Java code is trivial. The real work is all handled by an abstract
> >> class. The reason we have to have to write a bit of Java is because
> >> a) m2, at least currently, has no way to do "annotation-based
> >> pulls of
> >> POM <configuration> properties" in any but the base class -- when
> >> these classes are in separate jars.
> >>
> >
> > Correct, although that's not an issue. The only info you need comes
> > from the MavenProject object, which is available in for instance
> > the AntRun plugin. It has it's own PropertyHelper that allows you
> > to use ${project.*} expressions.
> >
> >
> >> b) But even if it could, you will still need to pull these properties
> >> and pass them on to Ant. That's' pretty much all that the Java code
> >> does. (although, yes, I think this could maybe be generalized when
> >> (a)
> >> is fixed)
> >>
> >
> > It's already working, I don't quite get what you mean? Why would
> > you need java code to pass on the properties when they're already
> > available?
> >
> >
> >> c) We want reusable Plugins. (E.g. I have an Axis plugin that I
> >> use in
> >> many projects.) This plugin contains it's Ant buildfile (e.g.
> >> axis-build.xml), and needs to have a Mojo associated with it (AFAIK).
> >> There are specifics to each AntFile usage such as what target to
> >> call,
> >> the name of the buildfile (it cannot be build.xml because it will
> >> likely clash with other AntFile uses), and properties (with
> >> defaults).
> >> IMO, this is not necessarily a Bad Thing.
> >>
> >
> > You can use <antcall dir="..." file="..."/> with the AntRun plugin
> > if you
> > want.
> >
> > Also, you can just embed the ant script in the 'plugin' pom, and just
> > extend from it. You can use pluginManagement in your project
> > to accomplish this. However, this is not exactly the same as
> > just depending on a plugin. But ofcourse there are ways to let
> > the antrun plugin load some 3rd party dep and specify in the
> > <configuration> where the build file is from that dep you want to
> > run, or
> > the task. But I guess that's what your AntFile plugin does above
> > the features of the AntRun plugin.
> >
> > Btw, I don't get why you extend the AntRun plugin - it's magic comes
> > from the custom PlexusComponentConfigurator so embedded xml can be
> > used as
> > an ant script snippet. If you are pulling external build.xml's from
> > a jar, you don't need the AntRun plugin as a basis.
> >
> > Maybe we can merge your AntFile code to the AntRun plugin, so you
> > can either specify nested ant script or refer to some buildfile.
> >
> >>> 2. Is this a stop gap plugin until John 'persuades' ;) his client to
> >>> let him reuse some wrapper archetecture to dynamically create ant
> >>> property delegates - or does it achieve something slightly
> >>> different?
> >>>
> >>
> >> Again, I think for reuasability you will want to have specific
> >> plugins
> >> which handle chunks of your build, which have to be layered into the
> >> m2 phases.
> >>
> >
> > M2 already does the chunk of the build.. why would you replicate
> > with ant
> > scripts what we've worked so hard for to do with maven itself? :)
> >
> >
> >> So you might have an Ant-based build that you're converting to m2.
> >> Let's assume that ~80% is directly convertible to m2, and there are,
> >> say, 2 things that are specific to your needs-- at, say, 2 different
> >> phases of the Ant build. These should be pulled into 2 m2 plugins
> >> that
> >> you layer into the general m2 sequence.
> >>
> >
> > .. or just bind the AntRun plugin to these two phases and paste the
> > snippets there. Saves you writing 2 plugins. And if you were writing 2
> > plugins, why not make them native? Or run the AntTasks directly,
> > without people having to specify some scriptlet code (or embedding
> > scriptlet code in the plugin..)..?
> >
> >
> >> It is my experience that if you need some ability in one build, you
> >> will likely need it in your next build. They are typically "company
> >> build policy" and not build-specific
> >>
> >
> > True.. reusable plugins are the reason those things are plugins,
> > else they
> > would be ant scripts.. ;)
> >
> >
> >>> 3. Are you talking about invoking isolated ant tasks or whole ant
> >>> build files or both? Are you suggesting that ant basically becomes
> >>> another plugin language encapsulated in its own build file -
> >>> could be
> >>> very useful.
> >>>
> >>
> >> Absolutely. I would like to see m2 embrace Ant as a "plugin language"
> >> -- perhaps as it's primary extension language. IMO, m2 would get
> >> tremendous adoption if it took this stance.
> >>
> >
> > The risk of doing this is that people don't learn what maven
> > already does,
> > and just create one big build.xml that does the whole build for them.
> > This is more maven 1 style - except targets you have preGoals/
> > postGoals
> > or 'phaseBindings', but the contents would be ant.
> > This is exactly why maven was created: just specify where your
> > (re)resources are, what type of artifact you want, optionally add
> > non-standard build steps using generally available plugins, and let
> > maven
> > do the rest.
> >
> >
> >> I have no desire to reinvent everything that Ant already does.
> >> And, as
> >> we all know, it is pretty easy to scrounge up Ant Tasks that do
> >> whatever you're after somewhere on the Net. So why recode it and
> >> debug
> >> it. Either programmatically build the Tasks in your Mojo (which can
> >> get a little long-winded) -- or just use a buildfile...
> >>
> >
> > Well, you've got a good point there. But I don't see what could be
> > established by an Ant task that you can't do directly with the library
> > that's behind it. Almost all core ant functionality is present in
> > Maven 2,
> > and the optional tasks are just wrappers around 3rd party libs.
> > They offer
> > an interface (or glue) to a build system, in this case ant. Maven2
> > has a
> > different interface, the plugins. It would be best to just use that
> > interface instead of creating another layer of glue between each
> > 3rd party
> > lib and maven2 (maven2 -> plugin -> glue -> ant -> glue -> 3rd
> > party lib).
> >
> > But on the other hand, reusing what's there is never bad. And if you
> > have 1 layer of glue that will enable you to stick any ant task to it,
> > you're really done with one plugin.
> >
> > (in fact, you could create a new lifecycle for maven, with 1 phase,
> > to which you attach an ant plugin, and let that execute the build..
> > but I
> > don't think that's the idea ;))
> >
> >
> >>> I'd definitely welcome the option to embed ant tasks directly within
> >>> a pom, preserving the exact same ant syntax, like I think antrun
> >>> does
> >>> - only benefiting from automatic maven properties and invoked in the
> >>> same jvm as discussed a while ago.
> >>>
> >
> > Yes it does, the <tasks> tag is actually a <target> tag, so you
> > can just add tasks that are below a <target> in a build file. I did
> > this
> > as to not encourage people to embed entire buildfiles, and keep the
> > task
> > at hand as simple as possible. It's actually meant for prototyping
> > (and discovering the need) of not-yet available plugins.
> >
> >
> >> Agreed. But this is isolated to that POM, so it's useful, but not
> >> reusable. There will be cases where this makes the most sense, and
> >> case where reusability is important.
> >>
> >
> > True, but the main idea is still: KISS! Say I want a deploy task,
> > because Cargo doesn't have a container deploy plugin yet. I just need
> > a <copy> tag, 1 line, very simple. It's meant for those things.
> > If it gets bigger than a few lines and it's possible to re-use it,
> > it should ofcourse go in a separate plugin. But then the question
> > arrises:
> > create an ant script and wrap a m2 plugin around that to configure the
> > script, or just create a pure Mojo?
> >
> > But, ofcourse I see the benefits of this (else the antrun plugin
> > probably wouldn't have existed), but I'm afraid if everybody can do it
> > with ant, they won't take the time to write a great maven2 plugin
> > that's
> > far more reusable than a customized ant script.
> >
> > Anyway, my 2 cents!
> >
> > -- Kenney
> >
> > ---------------------------------------------------------------------
> > 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
>
--
Kenney Westerhof
http://www.neonics.com
GPG public key: http://www.gods.nl/~forge/kenneyw.key
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: [m2] antfile plugin (was: "whether to use ant")
Posted by Chris Berry <ch...@gmail.com>.
On 9/15/05, Ashley Williams <ag...@mac.com> wrote:
> ROFL! Dude, I must put the record straight: Ashley not Ashleigh ...
> Glen not Glenda if you get what I mean!!!
eeek. sorry about that.
Although you completely blew my mental image ;-)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: [m2] antfile plugin (was: "whether to use ant")
Posted by Andrew Wilcox <aw...@unpuzzled.com>.
How do I configure Maven 2.0 to include the jdk tools.jar file in the build
process?
Andrew Wilcox
Re: [m2] antfile plugin (was: "whether to use ant")
Posted by Chris Berry <ch...@gmail.com>.
If you are interested in seeing this stuff in action I have entered an
enhancement request in Maven's Jira. (Per John's request)
This Jira entry contains a ZIP which has a full example of what I'm
describing -- including the axisant plugin -- which extends the
antfile plugin. And a my-app, which shows the axisant plugin in action
-- completing the usage picture.
The Jira entry is under maven-antrun-plugin
BTW: Kenney, this also contains some mods to enable Ant <echo>
Cheers,
-- Chris
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: [m2] antfile plugin (was: "whether to use ant")
Posted by Kenney Westerhof <ke...@apache.org>.
On Thu, 15 Sep 2005, Ashley Williams wrote:
Would've been too good to be true.. :)
> ROFL! Dude, I must put the record straight: Ashley not Ashleigh ...
> Glen not Glenda if you get what I mean!!!
>
> On 15 Sep 2005, at 19:26, Chris Berry wrote:
>
> > I agree w/ Ashley (hopefully I'm not putting words in her mouth ;-).
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
--
Kenney Westerhof
http://www.neonics.com
GPG public key: http://www.gods.nl/~forge/kenneyw.key
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: [m2] antfile plugin (was: "whether to use ant")
Posted by Ashley Williams <ag...@mac.com>.
ROFL! Dude, I must put the record straight: Ashley not Ashleigh ...
Glen not Glenda if you get what I mean!!!
On 15 Sep 2005, at 19:26, Chris Berry wrote:
> I agree w/ Ashley (hopefully I'm not putting words in her mouth ;-).
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: [m2] antfile plugin (was: "whether to use ant")
Posted by Chris Berry <ch...@gmail.com>.
On 9/15/05, Ashley Williams <ag...@mac.com> wrote:
> I've actually been talking about ant tasks, whereas I think Chris
> (correct me if I'm wrong) was talking about whole build.xml files. I
> don't see this as somehow replacing any of what Maven has to offer,
> it just offers another language for writing plugins in besides java.
> I mean how much more damage can I do in ant than I can do in Java ;)
I am talking about whole build files, although ones that are likely
single purpose.
Case in point; I have an Axis build file that ultimately uses the
Axis-provided ant task; wsdl2java. But this build step (generating
Java Stubs, Proxies, etc from a WSDL) is significantly more
complicated than that. It actually requires many internal targets to
accomplish (e.g. check if files are up-to-date, HTTP GET the WSDL if
it's not local, disallow RPC-style WSDL, copy the gen-ed files, etc.
etc.) In the end, it's ~325 lines of Ant. My job was only to script it
-- not to code or debug the underlying Tasks. That would be a waste of
my time...
I agree w/ Ashley (hopefully I'm not putting words in her mouth ;-).
It is in no way perverse to embed Ant. And it in no way undermines the
usefulness of Maven. On the contrary, it opens up Maven to a huge
realm of possibility. To me it is akin to Ant providing an <exec>
Task. Sometimes you have no choice but to wrap out to something else.
It's all about getting the job done -- and the right tool for the job.
In fact, IMO, Maven should provide the same sort of interoperability
w/ Python, Ruby, and Perl. Embrace them and make them first class
citizens. As we all know, one can do magic in, say, Perl, that is much
too long-winded in Java.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: [m2] antfile plugin (was: "whether to use ant")
Posted by Ashley Williams <ag...@mac.com>.
Hi Kenney,
Don't know about you but I'm definitely getting bogged down by the
details of the technology so I'm focused on the high level details
here...
There are an enormous number of ant tasked to be scrounged as Chris
put it and IMHO it would be insane for maven to try to rewrite them.
For one it would cost effort and two you would lose that comfort
factor that people have from years of Ant experience.
I'm far from an expert in Maven. But I do know that if an ant task
were wrapped inside a mojo then you wouldn't be able to tell the
difference between it and any other mojo that didn't have any ant
magic inside - apart from some really familiar looking ant syntax
right there in the pom. Therefore I don't understand the comment that
it can't be reused in the same way.
Related to this I see some ant tasks as very special. For example you
might expect that an ant tomcat task embedded in your pom would
already know where to find your deployable war file to save you
configuring that particular property. Therefore the mojo (container?
wrapper?decorator?bridge?) would know how to pass some of those maven
properties to the corresponding ant properties perhaps by consulting
a text file map.
I've actually been talking about ant tasks, whereas I think Chris
(correct me if I'm wrong) was talking about whole build.xml files. I
don't see this as somehow replacing any of what Maven has to offer,
it just offers another language for writing plugins in besides java.
I mean how much more damage can I do in ant than I can do in Java ;)
Sounds as if there might be some overlap between the two ant plugins
discussed here - ant targets and whole build files - it would be
interesting to see if they could combined.
-AW
On 15 Sep 2005, at 17:44, Kenney Westerhof wrote:
> On Thu, 15 Sep 2005, Chris Berry wrote:
>
> Hi,
>
> Let me step in for a moment here... ;)
>
>
>>> 1. I'm concerned that I have to write java code in order to call ant
>>> tasks. For example to support the tomcat task, would I or somebody
>>> else have to have extended the antfile plugin?
>>>
>>
>> The Java code is trivial. The real work is all handled by an abstract
>> class. The reason we have to have to write a bit of Java is because
>> a) m2, at least currently, has no way to do "annotation-based
>> pulls of
>> POM <configuration> properties" in any but the base class -- when
>> these classes are in separate jars.
>>
>
> Correct, although that's not an issue. The only info you need comes
> from the MavenProject object, which is available in for instance
> the AntRun plugin. It has it's own PropertyHelper that allows you
> to use ${project.*} expressions.
>
>
>> b) But even if it could, you will still need to pull these properties
>> and pass them on to Ant. That's' pretty much all that the Java code
>> does. (although, yes, I think this could maybe be generalized when
>> (a)
>> is fixed)
>>
>
> It's already working, I don't quite get what you mean? Why would
> you need java code to pass on the properties when they're already
> available?
>
>
>> c) We want reusable Plugins. (E.g. I have an Axis plugin that I
>> use in
>> many projects.) This plugin contains it's Ant buildfile (e.g.
>> axis-build.xml), and needs to have a Mojo associated with it (AFAIK).
>> There are specifics to each AntFile usage such as what target to
>> call,
>> the name of the buildfile (it cannot be build.xml because it will
>> likely clash with other AntFile uses), and properties (with
>> defaults).
>> IMO, this is not necessarily a Bad Thing.
>>
>
> You can use <antcall dir="..." file="..."/> with the AntRun plugin
> if you
> want.
>
> Also, you can just embed the ant script in the 'plugin' pom, and just
> extend from it. You can use pluginManagement in your project
> to accomplish this. However, this is not exactly the same as
> just depending on a plugin. But ofcourse there are ways to let
> the antrun plugin load some 3rd party dep and specify in the
> <configuration> where the build file is from that dep you want to
> run, or
> the task. But I guess that's what your AntFile plugin does above
> the features of the AntRun plugin.
>
> Btw, I don't get why you extend the AntRun plugin - it's magic comes
> from the custom PlexusComponentConfigurator so embedded xml can be
> used as
> an ant script snippet. If you are pulling external build.xml's from
> a jar, you don't need the AntRun plugin as a basis.
>
> Maybe we can merge your AntFile code to the AntRun plugin, so you
> can either specify nested ant script or refer to some buildfile.
>
>>> 2. Is this a stop gap plugin until John 'persuades' ;) his client to
>>> let him reuse some wrapper archetecture to dynamically create ant
>>> property delegates - or does it achieve something slightly
>>> different?
>>>
>>
>> Again, I think for reuasability you will want to have specific
>> plugins
>> which handle chunks of your build, which have to be layered into the
>> m2 phases.
>>
>
> M2 already does the chunk of the build.. why would you replicate
> with ant
> scripts what we've worked so hard for to do with maven itself? :)
>
>
>> So you might have an Ant-based build that you're converting to m2.
>> Let's assume that ~80% is directly convertible to m2, and there are,
>> say, 2 things that are specific to your needs-- at, say, 2 different
>> phases of the Ant build. These should be pulled into 2 m2 plugins
>> that
>> you layer into the general m2 sequence.
>>
>
> .. or just bind the AntRun plugin to these two phases and paste the
> snippets there. Saves you writing 2 plugins. And if you were writing 2
> plugins, why not make them native? Or run the AntTasks directly,
> without people having to specify some scriptlet code (or embedding
> scriptlet code in the plugin..)..?
>
>
>> It is my experience that if you need some ability in one build, you
>> will likely need it in your next build. They are typically "company
>> build policy" and not build-specific
>>
>
> True.. reusable plugins are the reason those things are plugins,
> else they
> would be ant scripts.. ;)
>
>
>>> 3. Are you talking about invoking isolated ant tasks or whole ant
>>> build files or both? Are you suggesting that ant basically becomes
>>> another plugin language encapsulated in its own build file -
>>> could be
>>> very useful.
>>>
>>
>> Absolutely. I would like to see m2 embrace Ant as a "plugin language"
>> -- perhaps as it's primary extension language. IMO, m2 would get
>> tremendous adoption if it took this stance.
>>
>
> The risk of doing this is that people don't learn what maven
> already does,
> and just create one big build.xml that does the whole build for them.
> This is more maven 1 style - except targets you have preGoals/
> postGoals
> or 'phaseBindings', but the contents would be ant.
> This is exactly why maven was created: just specify where your
> (re)resources are, what type of artifact you want, optionally add
> non-standard build steps using generally available plugins, and let
> maven
> do the rest.
>
>
>> I have no desire to reinvent everything that Ant already does.
>> And, as
>> we all know, it is pretty easy to scrounge up Ant Tasks that do
>> whatever you're after somewhere on the Net. So why recode it and
>> debug
>> it. Either programmatically build the Tasks in your Mojo (which can
>> get a little long-winded) -- or just use a buildfile...
>>
>
> Well, you've got a good point there. But I don't see what could be
> established by an Ant task that you can't do directly with the library
> that's behind it. Almost all core ant functionality is present in
> Maven 2,
> and the optional tasks are just wrappers around 3rd party libs.
> They offer
> an interface (or glue) to a build system, in this case ant. Maven2
> has a
> different interface, the plugins. It would be best to just use that
> interface instead of creating another layer of glue between each
> 3rd party
> lib and maven2 (maven2 -> plugin -> glue -> ant -> glue -> 3rd
> party lib).
>
> But on the other hand, reusing what's there is never bad. And if you
> have 1 layer of glue that will enable you to stick any ant task to it,
> you're really done with one plugin.
>
> (in fact, you could create a new lifecycle for maven, with 1 phase,
> to which you attach an ant plugin, and let that execute the build..
> but I
> don't think that's the idea ;))
>
>
>>> I'd definitely welcome the option to embed ant tasks directly within
>>> a pom, preserving the exact same ant syntax, like I think antrun
>>> does
>>> - only benefiting from automatic maven properties and invoked in the
>>> same jvm as discussed a while ago.
>>>
>
> Yes it does, the <tasks> tag is actually a <target> tag, so you
> can just add tasks that are below a <target> in a build file. I did
> this
> as to not encourage people to embed entire buildfiles, and keep the
> task
> at hand as simple as possible. It's actually meant for prototyping
> (and discovering the need) of not-yet available plugins.
>
>
>> Agreed. But this is isolated to that POM, so it's useful, but not
>> reusable. There will be cases where this makes the most sense, and
>> case where reusability is important.
>>
>
> True, but the main idea is still: KISS! Say I want a deploy task,
> because Cargo doesn't have a container deploy plugin yet. I just need
> a <copy> tag, 1 line, very simple. It's meant for those things.
> If it gets bigger than a few lines and it's possible to re-use it,
> it should ofcourse go in a separate plugin. But then the question
> arrises:
> create an ant script and wrap a m2 plugin around that to configure the
> script, or just create a pure Mojo?
>
> But, ofcourse I see the benefits of this (else the antrun plugin
> probably wouldn't have existed), but I'm afraid if everybody can do it
> with ant, they won't take the time to write a great maven2 plugin
> that's
> far more reusable than a customized ant script.
>
> Anyway, my 2 cents!
>
> -- Kenney
>
> ---------------------------------------------------------------------
> 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 (was: "whether to use ant")
Posted by Kenney Westerhof <ke...@apache.org>.
On Thu, 15 Sep 2005, Chris Berry wrote:
Hi,
Let me step in for a moment here... ;)
> > 1. I'm concerned that I have to write java code in order to call ant
> > tasks. For example to support the tomcat task, would I or somebody
> > else have to have extended the antfile plugin?
>
> The Java code is trivial. The real work is all handled by an abstract
> class. The reason we have to have to write a bit of Java is because
> a) m2, at least currently, has no way to do "annotation-based pulls of
> POM <configuration> properties" in any but the base class -- when
> these classes are in separate jars.
Correct, although that's not an issue. The only info you need comes
from the MavenProject object, which is available in for instance
the AntRun plugin. It has it's own PropertyHelper that allows you
to use ${project.*} expressions.
> b) But even if it could, you will still need to pull these properties
> and pass them on to Ant. That's' pretty much all that the Java code
> does. (although, yes, I think this could maybe be generalized when (a)
> is fixed)
It's already working, I don't quite get what you mean? Why would
you need java code to pass on the properties when they're already
available?
> c) We want reusable Plugins. (E.g. I have an Axis plugin that I use in
> many projects.) This plugin contains it's Ant buildfile (e.g.
> axis-build.xml), and needs to have a Mojo associated with it (AFAIK).
> There are specifics to each AntFile usage such as what target to call,
> the name of the buildfile (it cannot be build.xml because it will
> likely clash with other AntFile uses), and properties (with defaults).
> IMO, this is not necessarily a Bad Thing.
You can use <antcall dir="..." file="..."/> with the AntRun plugin if you
want.
Also, you can just embed the ant script in the 'plugin' pom, and just
extend from it. You can use pluginManagement in your project
to accomplish this. However, this is not exactly the same as
just depending on a plugin. But ofcourse there are ways to let
the antrun plugin load some 3rd party dep and specify in the
<configuration> where the build file is from that dep you want to run, or
the task. But I guess that's what your AntFile plugin does above
the features of the AntRun plugin.
Btw, I don't get why you extend the AntRun plugin - it's magic comes
from the custom PlexusComponentConfigurator so embedded xml can be used as
an ant script snippet. If you are pulling external build.xml's from
a jar, you don't need the AntRun plugin as a basis.
Maybe we can merge your AntFile code to the AntRun plugin, so you
can either specify nested ant script or refer to some buildfile.
> > 2. Is this a stop gap plugin until John 'persuades' ;) his client to
> > let him reuse some wrapper archetecture to dynamically create ant
> > property delegates - or does it achieve something slightly different?
>
> Again, I think for reuasability you will want to have specific plugins
> which handle chunks of your build, which have to be layered into the
> m2 phases.
M2 already does the chunk of the build.. why would you replicate with ant
scripts what we've worked so hard for to do with maven itself? :)
> So you might have an Ant-based build that you're converting to m2.
> Let's assume that ~80% is directly convertible to m2, and there are,
> say, 2 things that are specific to your needs-- at, say, 2 different
> phases of the Ant build. These should be pulled into 2 m2 plugins that
> you layer into the general m2 sequence.
.. or just bind the AntRun plugin to these two phases and paste the
snippets there. Saves you writing 2 plugins. And if you were writing 2
plugins, why not make them native? Or run the AntTasks directly,
without people having to specify some scriptlet code (or embedding
scriptlet code in the plugin..)..?
> It is my experience that if you need some ability in one build, you
> will likely need it in your next build. They are typically "company
> build policy" and not build-specific
True.. reusable plugins are the reason those things are plugins, else they
would be ant scripts.. ;)
> > 3. Are you talking about invoking isolated ant tasks or whole ant
> > build files or both? Are you suggesting that ant basically becomes
> > another plugin language encapsulated in its own build file - could be
> > very useful.
>
> Absolutely. I would like to see m2 embrace Ant as a "plugin language"
> -- perhaps as it's primary extension language. IMO, m2 would get
> tremendous adoption if it took this stance.
The risk of doing this is that people don't learn what maven already does,
and just create one big build.xml that does the whole build for them.
This is more maven 1 style - except targets you have preGoals/postGoals
or 'phaseBindings', but the contents would be ant.
This is exactly why maven was created: just specify where your
(re)resources are, what type of artifact you want, optionally add
non-standard build steps using generally available plugins, and let maven
do the rest.
> I have no desire to reinvent everything that Ant already does. And, as
> we all know, it is pretty easy to scrounge up Ant Tasks that do
> whatever you're after somewhere on the Net. So why recode it and debug
> it. Either programmatically build the Tasks in your Mojo (which can
> get a little long-winded) -- or just use a buildfile...
Well, you've got a good point there. But I don't see what could be
established by an Ant task that you can't do directly with the library
that's behind it. Almost all core ant functionality is present in Maven 2,
and the optional tasks are just wrappers around 3rd party libs. They offer
an interface (or glue) to a build system, in this case ant. Maven2 has a
different interface, the plugins. It would be best to just use that
interface instead of creating another layer of glue between each 3rd party
lib and maven2 (maven2 -> plugin -> glue -> ant -> glue -> 3rd party lib).
But on the other hand, reusing what's there is never bad. And if you
have 1 layer of glue that will enable you to stick any ant task to it,
you're really done with one plugin.
(in fact, you could create a new lifecycle for maven, with 1 phase,
to which you attach an ant plugin, and let that execute the build.. but I
don't think that's the idea ;))
> > I'd definitely welcome the option to embed ant tasks directly within
> > a pom, preserving the exact same ant syntax, like I think antrun does
> > - only benefiting from automatic maven properties and invoked in the
> > same jvm as discussed a while ago.
Yes it does, the <tasks> tag is actually a <target> tag, so you
can just add tasks that are below a <target> in a build file. I did this
as to not encourage people to embed entire buildfiles, and keep the task
at hand as simple as possible. It's actually meant for prototyping
(and discovering the need) of not-yet available plugins.
> Agreed. But this is isolated to that POM, so it's useful, but not
> reusable. There will be cases where this makes the most sense, and
> case where reusability is important.
True, but the main idea is still: KISS! Say I want a deploy task,
because Cargo doesn't have a container deploy plugin yet. I just need
a <copy> tag, 1 line, very simple. It's meant for those things.
If it gets bigger than a few lines and it's possible to re-use it,
it should ofcourse go in a separate plugin. But then the question arrises:
create an ant script and wrap a m2 plugin around that to configure the
script, or just create a pure Mojo?
But, ofcourse I see the benefits of this (else the antrun plugin
probably wouldn't have existed), but I'm afraid if everybody can do it
with ant, they won't take the time to write a great maven2 plugin that's
far more reusable than a customized ant script.
Anyway, my 2 cents!
-- Kenney
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: [m2] antfile plugin (was: "whether to use ant")
Posted by Chris Berry <ch...@gmail.com>.
Hi Ashley,
comments inline.
Cheers,
-- Chris
On 9/15/05, Ashley Williams <ag...@mac.com> wrote:
> (Chris)
>
> Pleased to see fellow users steering Maven more in the direction of
> ant and I have a few questions about this new plugin.
>
> 1. I'm concerned that I have to write java code in order to call ant
> tasks. For example to support the tomcat task, would I or somebody
> else have to have extended the antfile plugin?
The Java code is trivial. The real work is all handled by an abstract
class. The reason we have to have to write a bit of Java is because
a) m2, at least currently, has no way to do "annotation-based pulls of
POM <configuration> properties" in any but the base class -- when
these classes are in separate jars.
b) But even if it could, you will still need to pull these properties
and pass them on to Ant. That's' pretty much all that the Java code
does. (although, yes, I think this could maybe be generalized when (a)
is fixed)
c) We want reusable Plugins. (E.g. I have an Axis plugin that I use in
many projects.) This plugin contains it's Ant buildfile (e.g.
axis-build.xml), and needs to have a Mojo associated with it (AFAIK).
There are specifics to each AntFile usage such as what target to call,
the name of the buildfile (it cannot be build.xml because it will
likely clash with other AntFile uses), and properties (with defaults).
IMO, this is not necessarily a Bad Thing.
> 2. Is this a stop gap plugin until John 'persuades' ;) his client to
> let him reuse some wrapper archetecture to dynamically create ant
> property delegates - or does it achieve something slightly different?
Again, I think for reuasability you will want to have specific plugins
which handle chunks of your build, which have to be layered into the
m2 phases.
So you might have an Ant-based build that you're converting to m2.
Let's assume that ~80% is directly convertible to m2, and there are,
say, 2 things that are specific to your needs-- at, say, 2 different
phases of the Ant build. These should be pulled into 2 m2 plugins that
you layer into the general m2 sequence.
It is my experience that if you need some ability in one build, you
will likely need it in your next build. They are typically "company
build policy" and not build-specific
> 3. Are you talking about invoking isolated ant tasks or whole ant
> build files or both? Are you suggesting that ant basically becomes
> another plugin language encapsulated in its own build file - could be
> very useful.
Absolutely. I would like to see m2 embrace Ant as a "plugin language"
-- perhaps as it's primary extension language. IMO, m2 would get
tremendous adoption if it took this stance.
I have no desire to reinvent everything that Ant already does. And, as
we all know, it is pretty easy to scrounge up Ant Tasks that do
whatever you're after somewhere on the Net. So why recode it and debug
it. Either programmatically build the Tasks in your Mojo (which can
get a little long-winded) -- or just use a buildfile...
>
> I'd definitely welcome the option to embed ant tasks directly within
> a pom, preserving the exact same ant syntax, like I think antrun does
> - only benefiting from automatic maven properties and invoked in the
> same jvm as discussed a while ago.
Agreed. But this is isolated to that POM, so it's useful, but not
reusable. There will be cases where this makes the most sense, and
case where reusability is important.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: [m2] antfile plugin (was: "whether to use ant")
Posted by Ashley Williams <ag...@mac.com>.
(Chris)
Pleased to see fellow users steering Maven more in the direction of
ant and I have a few questions about this new plugin.
1. I'm concerned that I have to write java code in order to call ant
tasks. For example to support the tomcat task, would I or somebody
else have to have extended the antfile plugin?
2. Is this a stop gap plugin until John 'persuades' ;) his client to
let him reuse some wrapper archetecture to dynamically create ant
property delegates - or does it achieve something slightly different?
3. Are you talking about invoking isolated ant tasks or whole ant
build files or both? Are you suggesting that ant basically becomes
another plugin language encapsulated in its own build file - could be
very useful.
I'd definitely welcome the option to embed ant tasks directly within
a pom, preserving the exact same ant syntax, like I think antrun does
- only benefiting from automatic maven properties and invoked in the
same jvm as discussed a while ago.
AW
On 15 Sep 2005, at 15:11, John Casey wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Chris,
>
> Thanks for your contribution. I've been using little pieces of it in
> other stuff lately, but haven't had time to really get into
> integrating
> this into the M2 core yet. Would you be willing to file a JIRA
> issue for
> adding Ant the antfile plugin to the mix? I've been sort of putting it
> off, because I want to integrate Ant support in the same was that
> beanshell is integrated, for example.
>
> At this point, we're so heads down on getting to m2-final, that we
> need
> a central point of reference for any outstanding issues. Therefore,
> for
> better or worse, it'll be really hard to get any functionality not
> listed in JIRA into the m2 release. From personal experience, I can
> see
> that anything not in JIRA stands a decent chance of simply drowning in
> the noise.
>
> Thanks,
>
> John
>
> Chris Berry wrote:
> | Greetings,
> | There was a recent thread on "whether to use ant". It is a long
> thread
> | (19+ posts) and became divergent. So rather than bury that post
> there,
> | I will raise it here to the top level. Like people in that thread, I
> | firmly believe that a happy marriage between Maven and Ant is in the
> | best interest of all.
> |
> | When maven began it was really intended to be an easy way to
> share Ant
> | build scripts. We were all tired of reinventing the wheel. Every
> time
> | we started a new Ant project we had to copy in and customize a
> set of
> | Ant build scripts. With every new Ant project, we violated the
> Don't
> | Repeat Yourself" principle. Enhancements/bug fixes had to be hand
> | propagated across projects.
> |
> | Over time, maven became more than this. It added Good Stuff like the
> | POM (a holistic "recipe" for the project) and dependency management.
> | It added Bad Stuff, like Jelly. That's all water under the bridge.
> |
> | IMO, maven should emphatically refrain from reinventing the
> wheel. Ant
> | is the defacto Java build tool, although it is in no way limited to
> | Java. Ant already does ~90+% of the individual Tasks required by a
> | build system. And what it doesn't do is typically provided by others
> | wishing to either augment Ant's deficiencies (e.g. ant-contrib) or
> | wishing to have their tools adopted (e.g. axis-ant). Ant is
> | cross-platform, and is intended as a build tool -- not as a general
> | scripting language. Ant's original intent was simply to be a "better
> | make".
> |
> | Maven should concentrate on being the "glue" that holds it all
> | together -- providing value in reusability, repeatability, and
> | holistic project management.
> |
> | To this end, I have written an Antfile Plugin. It extends the AntRun
> | plugin, and simply allows you to delegate to an Ant buildfile. The
> | buildfile is rolled into the plugin jar, and then, is unzipped from
> | that jar into the /target and is run during the build.
> |
> | One simply extends the AntFile plugin with their own plugin,
> declaring
> | the buildfile, pulling config info from the POM and passing them
> on as
> | properties to Ant. It's very simple to use.
> |
> | (BTW: I have built an Axis plugin on top of this, validating it's
> usage pattern)
> |
> | I passed my AntRun plugin to John Casey (one of the Maven gurus),
> and
> | I hope that The Powers That Be will allow it into the HEAD of the
> SVN
> | tree.
> |
> | Cheers,
> | -- Chris
> |
> |
> ---------------------------------------------------------------------
> | 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)
>
> iD8DBQFDKYEWK3h2CZwO/4URAt2hAJ9nyagGeok+IjiJTt5m2Gyyxb3iBACfbG06
> MVTNja/5c7hnYd18vRD6cV0=
> =6dzQ
> -----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
Re: [m2] antfile plugin (was: "whether to use ant")
Posted by John Casey <jd...@commonjava.org>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Chris,
Thanks for your contribution. I've been using little pieces of it in
other stuff lately, but haven't had time to really get into integrating
this into the M2 core yet. Would you be willing to file a JIRA issue for
adding Ant the antfile plugin to the mix? I've been sort of putting it
off, because I want to integrate Ant support in the same was that
beanshell is integrated, for example.
At this point, we're so heads down on getting to m2-final, that we need
a central point of reference for any outstanding issues. Therefore, for
better or worse, it'll be really hard to get any functionality not
listed in JIRA into the m2 release. From personal experience, I can see
that anything not in JIRA stands a decent chance of simply drowning in
the noise.
Thanks,
John
Chris Berry wrote:
| Greetings,
| There was a recent thread on "whether to use ant". It is a long thread
| (19+ posts) and became divergent. So rather than bury that post there,
| I will raise it here to the top level. Like people in that thread, I
| firmly believe that a happy marriage between Maven and Ant is in the
| best interest of all.
|
| When maven began it was really intended to be an easy way to share Ant
| build scripts. We were all tired of reinventing the wheel. Every time
| we started a new Ant project we had to copy in and customize a set of
| Ant build scripts. With every new Ant project, we violated the Don't
| Repeat Yourself" principle. Enhancements/bug fixes had to be hand
| propagated across projects.
|
| Over time, maven became more than this. It added Good Stuff like the
| POM (a holistic "recipe" for the project) and dependency management.
| It added Bad Stuff, like Jelly. That's all water under the bridge.
|
| IMO, maven should emphatically refrain from reinventing the wheel. Ant
| is the defacto Java build tool, although it is in no way limited to
| Java. Ant already does ~90+% of the individual Tasks required by a
| build system. And what it doesn't do is typically provided by others
| wishing to either augment Ant's deficiencies (e.g. ant-contrib) or
| wishing to have their tools adopted (e.g. axis-ant). Ant is
| cross-platform, and is intended as a build tool -- not as a general
| scripting language. Ant's original intent was simply to be a "better
| make".
|
| Maven should concentrate on being the "glue" that holds it all
| together -- providing value in reusability, repeatability, and
| holistic project management.
|
| To this end, I have written an Antfile Plugin. It extends the AntRun
| plugin, and simply allows you to delegate to an Ant buildfile. The
| buildfile is rolled into the plugin jar, and then, is unzipped from
| that jar into the /target and is run during the build.
|
| One simply extends the AntFile plugin with their own plugin, declaring
| the buildfile, pulling config info from the POM and passing them on as
| properties to Ant. It's very simple to use.
|
| (BTW: I have built an Axis plugin on top of this, validating it's
usage pattern)
|
| I passed my AntRun plugin to John Casey (one of the Maven gurus), and
| I hope that The Powers That Be will allow it into the HEAD of the SVN
| tree.
|
| Cheers,
| -- Chris
|
| ---------------------------------------------------------------------
| 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)
iD8DBQFDKYEWK3h2CZwO/4URAt2hAJ9nyagGeok+IjiJTt5m2Gyyxb3iBACfbG06
MVTNja/5c7hnYd18vRD6cV0=
=6dzQ
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org