ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dominique Devienne" <>
Subject Re: EasyAnt <use>/<extends> vs <import>
Date Wed, 05 Nov 2008 18:30:44 GMT
On Wed, Nov 5, 2008 at 9:59 AM, Stefan Bodewig <> wrote:
> IIUC EasyAnt solits the two use-cases found for <import> into two
> logical tasks.
> * you never want to override a target, you just want to reuse them: <use>

That's an <include> to me. Rename <use> into <include>, and I'm +1,
even with the forced prefix (from build file or @as) to included

> * you may want to override some/most targets: <extends>

That's the current <import> indeed.

> Technically <extends> is what <import> is today.  <import>ed targets
> that haven't been overwritten in the main build are known under two
> names (prefixed and not prefixed) and the depends lists of the targets
> in the <extends>-imported file are not rewritten.
> Targets coming from a <use>d file only exist in their prefixed form
> and their dependencies are rewritten to include prefixes as well.
> I.e. you can not override the <use>d target's dependencies.
> There has been some confusion from time to time on the user list as to
> how you can ensure you get "your" target and not an overwritten one in
> an imported file, so I think <use> is useful outside of EasyAnt as
> well.
> EasyAnt also adds an as-attribute to <use> where the writer of the
> importing build file can control the prefix of the <use>d targets and
> overrules the <use>d project's name.  This makes sense IMHO.

It does to me too :)

> I'm not totally sure whether the as-attribute would make sense for
> <extends> as well, EasyAnt currently silently ignores it in that case.

It makes as much sense in <import> as it does in <include> to me, i.e.
to restore proper compartmentalization of the builds.

> Changes would be required to the import task as well as to
> ProjectHelper2 (the specific patch also patches AntXMLContext and
> ProjectHelper, but that may turn out to be not necessary.  It's an
> implementation detail).
> Opinions?

I don't think we should invent new terminology (use/extends) for
something that already exists (import) and it's natural equivalent to
use (include, which doesn't exist). The import/include difference
already exists in XSLT. It's not that import/include is *better* than
use/extends, it's that they are a fairly well known precedent,
especially given that we already have import in Ant.

What's missing from the above is the notion of TargetGroup to
implement the phase concept of EasyAnt (and Maven I guess). Although
it's possible to tack this on to Target, having a separate class to
model this would be better IMHO.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message