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]
