ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jose Alberto Fernandez" <>
Subject Re: cvs commit: jakarta-ant/src/testcases/org/apache/tools/ant/taskdefs
Date Tue, 11 Dec 2001 08:41:33 GMT
From: "Stefan Bodewig" <>

> On Mon, 10 Dec 2001, Jose Alberto Fernandez <>
> wrote:
> > From: "Stefan Bodewig" <>
> > 
> > Just thinking about the eventual unification of <property> and
> > <datatypes>, it would be nice if we could use the same "verb" to
> > refer to both when used as perameters,

That is why I suggested <param> beecause it does not say what they are
but what their function as parameters of the call. It is kind of odd
for a language to use different syntax depending on the type of the
argument, don't you think?. Are we going to add new <elements>
for every new kind of thingy we come up with? Sound silly to me... ;-)

> I'm not sure.  Properties and data types still are a bit different in
> Ant 1.x, especially if we remove the implicit copying for datatypes
> (which is where I'd like to see the behavior of properties end in Ant2
> as well).  You can override ids for datatypes just by redeclaring them
> for example.

You mean if I use the same ID twice the second one will win?
Humm, if that is the case, I would say that is a bug, not a feature.
And my reason for that is that by XML spec you are not supposed
to have two things with the same ID attribute in the same XML document.
Soooo, I would say that is bad bad bad :-)

> > If this is too risky, then I would suggest having <datatype>
> > inheritance be driven by a different attribute like:
> > "inheritrefs='true'" which by default is false.  But if set to true
> > will follow exactly the same rules of overriding as for properties.
> Works for me.

I think that would be much better and match what someone suggested
that inheritall do not pass datatypes by default.

One additional question.
Are you copying the objects or just passing copying the entries from the
IDs table? The reason I am asking is two fold:

1) If I remember correctly, datatypes are associated to a Project instance
during creation. If we just copy the reference, it means that there will be projects in
the new Project whose this.project points somewhere else. Are we aware
of the consequences of that? For example a <fileset> will be resolved
with respect to the "basedir" of the caller project. (which may be exactly
what we want, as long as we are aware that that is what it means).

2) <property> objects, IIRC, are also stored as references. Which means
that there would be two separate objects denoting the same thing
and which could be different. I may need to look again at ProjectHelper
since that is where I think we do that.

In any case, I think it is a move forward.

Jose Alberto

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

View raw message