ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Erik Hatcher" <>
Subject Re: Immutability improvement patch
Date Tue, 04 Dec 2001 00:25:58 GMT
----- Original Message -----
From: "Jose Alberto Fernandez" <>

>> How do we get a Project initialized with user properties without going
>> through a deprecated API?
>> Project.setUserProperty is still the same.
>> Here are some thoughts on how to proceed:
>> - Un-deprecate the piece in Property.addProperty where it calls
>> setUserProperty.

> -1

But its really the only easy way to accomplish allowing ant/antcall to
function as they used to without getting deprecation warnings for normal
activity... at least that I see.

And we just deprecated it.  With setUserProperty removed from Property (or
deprecated), the only way a user property could be set using Property is
through ant/antcall.  Sure its a hack, but no moreso than other things under
the hood.

>> - Keep setUserProperty deprecated (perhaps even remove it since only
>> <ant>/<antcall> relied on it, and it was never documented).

> Humm, what do we do with people that cut and paste from <ant> code :-(

cutting and pasting from an undocumented API sounds risky at best.  And if
they were, then they could still get through the back-door by using the new
Property constructor like I'm proposing.

>> - Add a constructor: Property(boolean userProperty) - this would get
>> from Ant.createProperty. - this would allow Property to set user
>> but only if the boolean argument constructor argument was called with
>> "true" - not something that could be done with a build file <property>.

> -1, this would allow developers to write tasks that modify properties
> which is exactly what we want to avoid.

We're leaving in Project.setProperty and Project.setUserProperty, so we
can't stop them from modifying properties.

> If I recall properly, we need to be able to construct a list of properties
> based on the merge of any user properties in the calling Project and
> any new properties defined in the invocation.

I thought that would be possible until I dug deeper and saw how the Property
task is being used under the hood.  The only other hack I thought of was to
construct a dummy Project and have Property run against it and pull the
properties from there and do the overlay that way.... but that seemed too

> This may require having a constructor with a signature like:

>    public Project(Project caller, Hashtable userProps);

> This constructor will take into account both set of properties.
> Then the code as today can set any other properties that may be inherited.

> What do you think?

Just won't work with the way ant/antcall use Property - that task is
associated with the new Project, and calls setNewProperty/setUserProperty on
it.  Only with a dummy Project in the middle to be used to build the
Hashtable, but that still relies on Property being able to override user

Despite the -1's, I'm going to submit my changes as a patch and let everyone
have a look.  They are much less painful than Jose makes it out to be, and
should do the trick.


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

View raw message