ant-dev mailing list archives

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

>> 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
called
>> from Ant.createProperty. - this would allow Property to set user
properties,
>> 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
involved.

> 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
properties.

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.

    Erik



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


Mime
View raw message