----- Original Message -----
From: "Jose Alberto Fernandez" <[EMAIL PROTECTED]>
>> 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:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
