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: override
Date: Mon, 4 Aug 2003 11:10:20 +0100
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Message-ID: <747F247264ECE34CA60E323FEF0CCC0C0F511E@london.cellectivity.com>
Thread-Topic: override
Thread-Index: AcNYFg2hmzZ90Db0Qyec8PH9zC33KQCVwmBw
From: "Jose Alberto Fernandez" <jalberto@cellectivity.com>
To: "Ant Developers List" <dev@ant.apache.org>

> From: Conor MacNeill [mailto:conor@cortexebusiness.com.au]
>=20
> On Fri, 1 Aug 2003 07:40 pm, Jose Alberto Fernandez wrote:
> >
> > OK, lets get on the nitty gritty of the matter. :-)
> >
> > What do you mean by unrelated imports? If they are=20
> unrelated why do you
> > need to import them toghether?=20
>=20
> They may be unrelated because they are written by different people.=20
>=20
> I will give an example. Let's say one person distributes a=20
> build fragment, a=20
> template really, for building a Java project. Someone else=20
> distributes a=20
> fragment to do documentation generation. In both cases I want=20
> to use the bulk=20
> of the template as is but I need to override some of the=20
> steps. In the java=20
> generation fragment I wish to add an xdoclet step before the=20
> compile step=20
> whereas in the documetation generation I have some funky logo=20
> processing that=20
> needs to be inserted into the document generation workflow.
>=20
> So it is this overriding that prevents me from using straight=20
> <ant>. The=20
> authors of the fragments can't know my special requirements=20
> but that is no=20
> problem as I can override some individual steps. The authors=20
> may have even=20
> inserted empty targets to make overriding easy - classic=20
> template method=20
> pattern.
>=20

What stops you from writing two separate buildfiles one for each
that perform the import and do the respective override. From your
main build you just <ant/> these new files.

> Unfortunately the authors of the two build fragments don't=20
> know of the=20
> existence of each other and used the same target names in=20
> their fragments=20
> whether it is a simple "init", "compile", "clean" or any of=20
> the other very=20
> common names you find in builds.
>=20
> > Why don't you use <ant/> to call between the
> > unrelated targets? In other words, the now famous example of "bad"
> > crosstalk, I could argue is due to bad usage of the=20
> <import/> feature.=20
>=20
> You could argue that but you'd be wrong :-)
>=20

My point in all these is that <import>ing all files toghether
may not be the only way (or the correct way) to solve every problem.
And the more I see at these examples the more I think that we are
going the spaggetti way; I think I preffered a well layered lassagna :-)

> > The
> > build should not have imported files A and B, but just=20
> <ant/> them. You
> > should have gotten the desired effect.
>=20
> No override - back to copy, paste and hack. I lose all the benefits.
>=20
> >
> > On the other hand, if you have to import them, then it is=20
> because they have
> > to share something or one defines some target for the=20
> other, or something.
>=20
> I disagree. Importing them into a common build does not imply=20
> they have=20
> something in common other than they are both fragments I wish=20
> to use in my=20
> build process. If you want them to interact you should achieve that=20
> *explicitly* by operations in the importing build file not by=20
> some implicit=20
> coincidence of names.
>=20

Well that is the way it works in OO programming. If you redefine
a signature, implicitly, you get the new behavior.

BTW, I am not against having some different approach as long as it is=20
well defined and not something that works for the two or three
scenarios that come to mind and breaks all over when users
try to do something interesting.

I would argue rewriting is not the solution. If we want what you
are saying, then we need a more richer execution context framework
where dependencies are selected depending on the target that
is citing them (and not just by name). All that is possible by just
managing better the symbol tables for targets.

Jose Alberto

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