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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
