Return-Path: 
 <dev-return-49330-apmail-ant-dev-archive=ant.apache.org@ant.apache.org>
Delivered-To: apmail-ant-dev-archive@ant.apache.org
Received: (qmail 8437 invoked by uid 500); 8 Aug 2003 17:34:20 -0000
Mailing-List: contact dev-help@ant.apache.org; run by ezmlm
Precedence: bulk
List-Unsubscribe: <mailto:dev-unsubscribe@ant.apache.org>
List-Subscribe: <mailto:dev-subscribe@ant.apache.org>
List-Help: <mailto:dev-help@ant.apache.org>
List-Post: <mailto:dev@ant.apache.org>
List-Id: "Ant Developers List" <dev.ant.apache.org>
Reply-To: "Ant Developers List" <dev@ant.apache.org>
Delivered-To: mailing list dev@ant.apache.org
Received: (qmail 8413 invoked from network); 8 Aug 2003 17:34:19 -0000
Received: from unknown (HELO london.cellectivity.com) (212.18.242.163)
  by daedalus.apache.org with SMTP; 8 Aug 2003 17:34:19 -0000
content-class: urn:content-classes:message
Subject: RE: override
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Fri, 8 Aug 2003 18:34:22 +0100
Message-ID: <747F247264ECE34CA60E323FEF0CCC0C0F5127@london.cellectivity.com>
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: override
Thread-Index: AcNdcp4dF1/RQ1GySVev9IsbzwJdIAAXDk6g
From: "Jose Alberto Fernandez" <jalberto@cellectivity.com>
To: "Ant Developers List" <dev@ant.apache.org>
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N

> From: Costin Manolache [mailto:cmanolache@yahoo.com]
>=20
> Jose Alberto Fernandez wrote:
>=20
> > One of the problems I have with the "rewriting" approach is=20
> that target
> > names get rewritten y the caller which means that two independent
> > importers may decide to use the same prefix and hence you=20
> get a clash.
> > Namespaces or java-style fully-qualified-names are a=20
> property intrinsic
> > of the imported file, that is the reason that makes it safe.
>=20
> That's why I think it's better to not try to be too flexible=20
> in allowing
> arbitrary rewriting, but do it in a canonical way:
>  - after a build.xml is read, all un-qualified names get=20
> prefixed with the=20
> project name and a delimiter ( need some tricks for ant-call, but it's
> possible )

Antcall is a call to the entire buildfile, since it will reload the =
build
file from the top. Hence I do not think we should rewrite here.=20
In any case, how do you deal with properties in the target attribute:

	<antcall target=3D"${picktarget}"/>

In my opinion, if you are writing buildfiles for reuse you should
make sure either not to use <antcall/> or instead use:

	<ant file=3D"${ant.file.thisfile}" target=3D"${picktarget}/>

In my experience most uses of <antcall/> can be rewritten into =
dependencies.

>  - you can call a target by the local name as long as it is unique,
> otherwise you need qualified names.
>=20
> No overloading, no conflicts, no abiguity.
>=20
As long as you cannot import two projects with the same name (but =
different file),
I agree this would be a possible solution.=20
This means targets may have multiple names (decorated and not =
decorated), yes?

>=20
> > Single inheritance (a la Java) requires having syntax that=20
> allows for
> > extending only once, something like:
> >=20
> >   <project name=3D"q" extends=3D"this/other/build.xml">...</project>
> >=20
> > if you use something like a task to specify the extend then=20
> you may write
> > multiple inheritance and all these ambiguities appear.
> > Could we live with single inheritance and <include/>=20
> instead of <import/>?
>=20
> My point is that <import> is different than "extneds".=20
>=20
>=20
> > The escenario is that you have your tipical:
> >=20
> > a
> >    target compile depends=3Dprecompile
> >    target precompile (do-nothing)
> >=20
> > b
> >    target precopile (very complex precompile lib)
> >=20
> > build:
> >    import (a,b)
> >=20
> > With cross-talk that is all you need to connect the two
> > and get the required effect. Without cross-talk you would=20
> need to add
> > more targets to build:
>=20
> With qnames there is no crosstalk.
>=20
> a
>    target a::compile depends a::precompile
>    target a::precompile
>=20
> b
>   target b::precompile
>=20
> build:
>   import a, b
>   You can call a::compile ( which will call a::precompile ), etc.
>=20
> =20
> >    target precompile depends=3Db.precompile
> >=20
> > or
> >=20
> >    override-target compile depends=3Db.precompile, super.compile
>=20
> Too complicated IMO.=20
>=20
> All import should do is load some build files and deal with the=20
> name conflicts in a clear way, without becoming a very hacky solution
> that nobody understand - and to be honest I have a lot of trouble=20
> understanding most of the overriding - even in the simple examples=20
> on the thread, I can't imagine what will happen when people=20
> start using this
> with dozens of targets.
>=20
>=20

This is exactly my point. If the feature is not properly defined
and all cases taken into consideration, people will get into trouble
when writing large build files. We already have people using things
like centepide that has inheritance and would like to have it directly
in ANT. Are there any interesting uses of inheritance there that we can
see. After all this feature is so that we address the need of real users
and not just a feature for feature sake.

As I said before, I do not presume to have all answers,

Jose Alberto


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