Mailing-List: contact dev-help@ant.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Ant Developers List" <dev@ant.apache.org>
content-class: urn:content-classes:message
Subject: RE: ant 1.5.4 : Import
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 30 Jul 2003 20:14:15 +0100
Message-ID: <747F247264ECE34CA60E323FEF0CCC0C0F5119@london.cellectivity.com>
Thread-Topic: ant 1.5.4 : Import
Thread-Index: AcNWd2TYsIsd5nEHSA6g8sQClFA3bQATcl9Q
From: "Jose Alberto Fernandez" <jalberto@cellectivity.com>
To: "Ant Developers List" <dev@ant.apache.org>

Guys,

I think that using C++ or C# as the model for ANT inheritance would be =
very bad.
As I remember, the rules for resolving multiple inheritance in C++ are
very complicated.

I would propose using the XSLT model. It is much more simple, it may not
allow for the example posted below as is, but I think it provides a well
defined model and a simple set of rules.

In escense, the idea is to associate a precedence to each target =
(template in XSLT)
and when we say target X in a dependency, what is meant is the highest =
precedence X.
No renaming necessary. Additionally, XSLT has an <apply-imports/> which =
would be=20
equivalent to having a task like: <call-import/>=20
which evaluates a target with the same name as the current target but =
comming from the
imported files (not taking into account the current target, nor targets =
on files
importing this build file).

How to associate precedences, very easy. If we have something like:

	a+---b---c
       \---d-+--e
        \--g  \-f

target precedence on each file will be:
  c=3D1 b=3D2 e=3D3 f=3D4 d=3D5 g=3D6 a=3D7

So if X is defined in c, e, and f; everybody will finish using the one =
in f.

If X calls <call-import/> then it will call the X in e, since it is the =
highest definition
lower than the X in f.

Shall <call-import/> execution make sure its dependencies have been =
executed? Or shall
it be executed without dependencies (That I do not know).

Notice that there is no need for renaming anything, just adding a =
precedence attribute
to each target. And precedences are assigned in a depth-first-search =
manner.

XSLT forces <imports> to be at the top of the file, which simplifies =
precedence computation.
We could enforce the same (what it really means, is no imports inside =
targets).

Well, hope you consider this, as an alternative. I think it is much more =
easy to handle
and if XSLTs do not need more that this, I do not see why ANT will need =
much more.

Cheers,

Jose Alberto

> -----Original Message-----
> From: Nicola Ken Barozzi [mailto:nicolaken@apache.org]
> Sent: 30 July 2003 09:46
> To: dev@ant.apache.org
> Subject: Re: ant 1.5.4 : Import
>=20
>=20
>=20
> Conor MacNeill wrote, On 30/07/2003 0.10:
>=20
> > On Tue, 29 Jul 2003 05:52 pm, Nicola Ken Barozzi wrote:
> >=20
> >>Personally, I don't see the real need for it, as the same=20
> can be done
> >>with correctly-written @importable files. In the specific,=20
> init values
> >>should be included rather than imported.
> >>
> >>Can you point me to some relevant use-cases?
> >=20
> > Ok, attached is a small test case which shows the failings=20
> of <import> when=20
> > there are target name collisions. In this case the=20
> dependency of "test" to=20
> > "critical" in b.xml is incorrectly replaced with a depenency on the=20
> > "critical" target in a.xml.=20
>=20
> Woah, this is a really nice test!
>=20
> I strongly encourage all that are interested in <import> to=20
> unzip it and=20
> run it, it's very insightful.
>=20
> > Target renaming doesn't help here. Having everything in a=20
> single project=20
> > namespace remains a problem. I'd say the number of target=20
> name collisions=20
> > between imported build files is going to be high because of=20
> the tendency to=20
> > choose target names from a small pool of common names.
>=20
> Houston, I think we have a potential problem here. You are right.
>=20
> I have never encountered this because I always write small imported=20
> files with not many targets, and each library has unique-name targets.
>=20
> The issue stems from the fact that overriding works also *between*=20
> imported files. So what happens is that an imported file silently is=20
> able to override a target in another imported file without me knowing=20
> it, and I agree that it's nasty.
>=20
> Let's see what the behaviour should be here.
>=20
> multi-import(import a,b)
>    target test depends=3Da.test, b.test
>=20
> a
>    target critical
>    target test depends=3Dcritical
>=20
> b
>    target critical
>    target test depends=3Dcritical
>=20
>=20
> Here "critical" means a.critical to a and b.critical to b, but since=20
> they reference a generic "critical", they get the only one=20
> that remains=20
> after being redefined. The problem is that I did not redefine=20
> it in the=20
> main buildfile!
>=20
> OTOMH this could be solved by rewriting all dependencies that=20
> are not in=20
> the import line.
>=20
>                (1)---a
>   multi-import (2)---b
>                (3)---c---d
>=20
> So rewriting should block collisions between (1), (2), (3),=20
> but enable=20
> them inside those lines.
>=20
> What had been proposed is using "fully qualified" names in=20
> targets that=20
> I do not want to be redefined, which could be ok=20
> conceptually, but the=20
> issue is that the implications of sideways crosstalk between import=20
> lines are not transparent to the user, and thus should be avoided.
>=20
> What I need is to be able to import build dependencies along with the=20
> targets. Probably the above solution should fix this error=20
> and make it=20
> work, no?
>=20
> Other suggestions on how to do it while keeping the=20
> functionality that=20
> import now gives?
>=20
> --=20
> Nicola Ken Barozzi                   nicolaken@apache.org
>              - verba volant, scripta manent -
>     (discussions get forgotten, just code remains)
> ---------------------------------------------------------------------
>=20
>=20
>=20
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
>=20
>=20

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