PropertyHelper data members should be protected, not private
-added protected accessors to the live data, so that we have more of a choke point on their use/abuse.
git-svn-id: https://svn.apache.org/repos/asf/ant/core/trunk@348764 13f79535-47bb-0310-9956-ffa450edef68
for threads that do not use properties.
This is a quick fix and not tested too much.
The whole thing may be scrapped...
git-svn-id: https://svn.apache.org/repos/asf/ant/core/trunk@277364 13f79535-47bb-0310-9956-ffa450edef68
for clarity. Fix cases where "property name" is logged as '${property name}'
as that notation more appropriately refers to the property's value.
git-svn-id: https://svn.apache.org/repos/asf/ant/core/trunk@277212 13f79535-47bb-0310-9956-ffa450edef68
Input is calling setNewProperty - but if defaultValue and value are null
we'll get NPE
PR:
Obtained from:
Submitted by:
Reviewed by:
git-svn-id: https://svn.apache.org/repos/asf/ant/core/trunk@273732 13f79535-47bb-0310-9956-ffa450edef68
This is "slightly" different from embed - if dynamic properties will be
accepted in 1.6, it is better to do it right. Embed uses few hacks to
trick the ProjectHelper.
PropertyHelper includes all the code related with property manipulation
from Project (cut&paste). I added a very simple hook mechanism ( Filter/Valve
like ) for the most common operations.
The API is obviously far from final - someone who really understand "user"
and "inherited" properties should review it and make few changes.
In Project, all properties fields are private - so all can be removed.
The methods related with properties will just delegate to PropertyHelper.
From a user point of view - no visible change ( hopefully :-). Even grant
will continue to work ( but won't be able to use the new features ).
Benefits:
- cleanup of Project. Less code and better organised.
- Property handling will hopefully be cleaner too
- we get to add APIs for namespace support, and maybe support non-string
properties ( JSP-EL like - that needs to be disussed, but IMO it would
be very helpfull ). While refs are Objects, the main distinction is imutability.
Also:
- apps embeding or extending ant can fully customize _all_ aspects of
property processing, including ${} replacement and even the syntax.
- it should be very easy to hook a different storage mechanism ( i.e.
integrated with the embeding app, without requiring copy of properties ).
- it should be possible to avoid copy when creating execution frames
( by using a chain that keeps changes and delegates getters ).
- dynamic properties support ( my original itch :-)
Please wait few days before firing, it seems all tests are passing
and gump works - but I'm sure there are few problems :-)
( I'll commit the change in Project later today )
PR:
Obtained from:
Submitted by:
Reviewed by:
git-svn-id: https://svn.apache.org/repos/asf/ant/core/trunk@273709 13f79535-47bb-0310-9956-ffa450edef68
Peter Reilly
Matthew Jason Benson
Stefan Bodewig
Steve Loughran
Antoine Levy-Lambert
Conor MacNeill
Costin Manolache