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: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
--
Kenney Westerhof
http://www.neonics.com
GPG public key: http://www.gods.nl/~forge/kenneyw.key
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
