ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Xavier Hanin" <xavier.ha...@gmail.com>
Subject Re: [DISCUSS] EasyAnt: Ant based pre packaged build system for java projects
Date Tue, 15 Jan 2008 08:05:27 GMT
On Jan 15, 2008 6:31 AM, Stefan Bodewig <bodewig@apache.org> wrote:

> "Peter Reilly" <peter.kitt.reilly@gmail.com> writes:
>
> > I would say that if the build file does not specify the order, then the
> order
> > is undefined.
> >
> > If the order is important, then the build file can enforce an order by
> > using "depends".
> >
> >     <target name="prepare" before="junit" depends="start-server">
> >        <prepare />
> >     </target>
>
> One thing we are not taking into account is the plugin approach that
> is part of Xavier's initial EasyAnt vision.
>
> If our base build file contains a compile target and several "plugins"
> that I want to use need to do stuff before the compile target then we
> need a way to have a defined order.  In the order my build file
> requires the plugins, I guess.

Yes, I agree order should be predictable, and keeping definition order seems
fine.

>
>
> Do we revert the order for after targets so the first one declared
> gets executed last?

Why not. But in my mind if you really need to do something surrounding a
target, you'd better use the around mechanism than the after / before. I
think it's more explicit.
The problem with the around mechanism as I see it (which is basically an
override with a mean to call the original definition) is the interaction
between plugins. If several plugins use the around mechanism, it maybe
difficult to understand that the call to the original defintion actually
call the definition overriden by another plugin. And if one plugin actually
overrides a definition without calling the original definition, then the
order will be very important: if it's defined after a plugin overriding just
for the around, then I guess the final override will override everything
including the overriden definition. So it's very different from what would
have happened while using a before and after targets (well, as I see it, see
below).

>
>
> Also we will need to define how before/after an complete overriding of
> targets interact.  Do before/after apply to the new definition of the
> target or are they dropped?

I'd say they apply to the new definition. If we take the example of the
server start / stop, I think it still makes sense to run 'em when another
plugin redefines how the unit tests are run. In my mind plugins interactions
should be kept minimal as long as they aren't explicitly desired. If a
plugin really wants to disable another plugin 'before' target, then we
should provide a mean to do it, like overriding the before target. I'm not
sure if there is a use case for that though. As I said before the main
problem about plugin interaction is when two plugins override the definition
of a target, and at least one doesn't call the original definition. Maybe
this shouldn't be considered at the same level: defining before and after
targets can be seen as a plugin contribution. Overriding a target is closer
to OO inheritance, and as such maybe could be allowed only when a build
script 'extends' another one.

Hence we would have two kind of relationship between build modules:
- a build module 'contributes' to another one, in which case it can only
define after/before targets. This is called a plugin.
- a build module 'extends' another one, in which case it can override parent
target(s) definition(s)

Only one 'extension' of a given module can be used at a time in the build
system, while the number of contributions is not limited.

Does this make sense?

Xavier

>
>
> Stefan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
>
>


-- 
Xavier Hanin - Independent Java Consultant
http://xhab.blogspot.com/
http://ant.apache.org/ivy/
http://www.xoocode.org/

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message