ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jose Alberto Fernandez" <>
Subject RE: Alias names for imported targets
Date Fri, 04 Jun 2004 18:21:03 GMT
> From: Stefan Bodewig [] 
> On Fri, 4 Jun 2004, Dominique Devienne <> wrote:
> > This allows to bypass the target override, and thus bypass whatever 
> > the overridden target does.
> Right.  But I already can bypass it if the target is 
> overridden since I get the aliased name then.  If this type 
> of bypassing is wrong, we shouldn't allow it in any way.

This is one of my pifs with the current import, a battle I think I lost.
Or maybe I won (I cannot remember which side I was :-(  )

As in any inheritance based language, what you need is two things:

1) Been able to override to change behaviour.
2) Been able, from the overriding module (project) to call the original
behaviour that you overrode(sp?).

(1) we acomplish, but (2) I do not think we did right.
Here what we needed was having "super" (or in our case since we have
multiple inheritance)
to be able to refer to several supers. But we did not do that, we do not
give access
just to the previous definitions (super) we kind of gave access to all
which I am sure will create spaguetti builds in the future.

I remember someone pointing out that our big mistake on <import/> was 
that we use the name of the project being imported and not a name local
to the importing 
build as the way to refer to "super", this in escence breaks visibility

So if we have:
<project name="foo">
  <target name="baz"/>

<project name="here">
  <import file="imported.xml"  id="there"/>

  <target name="baz" depends="foo.baz, there.baz"/>

The depends list shows the issue, the first target "foo.baz" requires
the writer of build.xml to know not only the name of the imported file
but also details about its content (beside the contract of providing a
"baz" target.

The second target "there.baz" does not require build.xml to know about
the internals of imported.xml. More over, there is no way to talk
about things further imported, since the only thing you have is your
local ids (or that is the idea).

Now this is not easy, since requires visibility rules much more dinamic
the syntactic rewriting we have today.

> I don't have a real world use-case, granted, my major reason 
> is consistency - I want to be able to write depends="" 
> and not care whether it has been overridden or not.

Not sure if this is just adding more logs into the fire (as we say in

Jose Alberto

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

View raw message