ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jose Alberto Fernandez" <>
Subject Re: Immutability improvement patch
Date Tue, 04 Dec 2001 00:51:44 GMT

Is it the main problem the fact that the code uses Property objects to do the job
or the fact that you cannot know the "user-properties" before you define
the new project? Or is it something else?

If what you need is the Property objects, one thing we could do is to subclass
them in an inner class of Project. (The subclass will be priveledge in the sense
that it would be able to set the property as a user property.

The regular Property will have setUserProperty as deprecated. So something like:

    public class Project .... {

        private static class UserProperty extends Property {

            UserProperty() { userProperty = true; }

Now within the code of the Project or some well defined segment,
you can define UserProperties which do the job as expected,
while in the outside world they are still not needed.

This is simillar to your idea of the new constructor, but with the
difference that general tasks cannot abuse it. And yes, I know the 
method will just be deprecated (and hence still available),
but I guess it should go thru the deprecation lifecycle of
eventually requiring -legacy for it to work.

Am I even in the general ballpark?

Jose Alberto
From: "Erik Hatcher" <>

> ----- 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
> 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:   <>
> For additional commands, e-mail: <>

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

View raw message