You can not select more than 25 topics Topics must start with a chinese character,a letter or number, can include dashes ('-') and can be up to 35 characters long.

PropertyHelper.java 37 kB

"Dynamic properties" and a bit more. 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
23 years ago
"Dynamic properties" and a bit more. 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
23 years ago
"Dynamic properties" and a bit more. 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
23 years ago
"Dynamic properties" and a bit more. 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
23 years ago
"Dynamic properties" and a bit more. 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
23 years ago
"Dynamic properties" and a bit more. 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
23 years ago
"Dynamic properties" and a bit more. 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
23 years ago
"Dynamic properties" and a bit more. 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
23 years ago
"Dynamic properties" and a bit more. 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
23 years ago
"Dynamic properties" and a bit more. 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
23 years ago
"Dynamic properties" and a bit more. 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
23 years ago
"Dynamic properties" and a bit more. 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
23 years ago
"Dynamic properties" and a bit more. 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
23 years ago
"Dynamic properties" and a bit more. 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
23 years ago
"Dynamic properties" and a bit more. 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
23 years ago
"Dynamic properties" and a bit more. 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
23 years ago
"Dynamic properties" and a bit more. 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
23 years ago
"Dynamic properties" and a bit more. 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
23 years ago
"Dynamic properties" and a bit more. 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
23 years ago
"Dynamic properties" and a bit more. 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
23 years ago
"Dynamic properties" and a bit more. 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
23 years ago
"Dynamic properties" and a bit more. 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
23 years ago
"Dynamic properties" and a bit more. 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
23 years ago
"Dynamic properties" and a bit more. 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
23 years ago
"Dynamic properties" and a bit more. 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
23 years ago
"Dynamic properties" and a bit more. 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
23 years ago
"Dynamic properties" and a bit more. 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
23 years ago
"Dynamic properties" and a bit more. 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
23 years ago
"Dynamic properties" and a bit more. 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
23 years ago
"Dynamic properties" and a bit more. 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
23 years ago
"Dynamic properties" and a bit more. 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
23 years ago
"Dynamic properties" and a bit more. 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
23 years ago
"Dynamic properties" and a bit more. 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
23 years ago
"Dynamic properties" and a bit more. 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
23 years ago
"Dynamic properties" and a bit more. 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
23 years ago
"Dynamic properties" and a bit more. 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
23 years ago
"Dynamic properties" and a bit more. 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
23 years ago
"Dynamic properties" and a bit more. 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
23 years ago
"Dynamic properties" and a bit more. 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
23 years ago
"Dynamic properties" and a bit more. 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
23 years ago
"Dynamic properties" and a bit more. 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
23 years ago
"Dynamic properties" and a bit more. 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
23 years ago
"Dynamic properties" and a bit more. 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
23 years ago
"Dynamic properties" and a bit more. 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
23 years ago
"Dynamic properties" and a bit more. 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
23 years ago
"Dynamic properties" and a bit more. 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
23 years ago
"Dynamic properties" and a bit more. 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
23 years ago
"Dynamic properties" and a bit more. 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
23 years ago
"Dynamic properties" and a bit more. 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
23 years ago
"Dynamic properties" and a bit more. 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
23 years ago
"Dynamic properties" and a bit more. 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
23 years ago
"Dynamic properties" and a bit more. 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
23 years ago
"Dynamic properties" and a bit more. 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
23 years ago
"Dynamic properties" and a bit more. 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
23 years ago
"Dynamic properties" and a bit more. 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
23 years ago
"Dynamic properties" and a bit more. 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
23 years ago
"Dynamic properties" and a bit more. 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
23 years ago
"Dynamic properties" and a bit more. 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
23 years ago
"Dynamic properties" and a bit more. 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
23 years ago
"Dynamic properties" and a bit more. 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
23 years ago
"Dynamic properties" and a bit more. 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
23 years ago
"Dynamic properties" and a bit more. 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
23 years ago
"Dynamic properties" and a bit more. 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
23 years ago
"Dynamic properties" and a bit more. 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
23 years ago
"Dynamic properties" and a bit more. 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
23 years ago
"Dynamic properties" and a bit more. 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
23 years ago
"Dynamic properties" and a bit more. 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
23 years ago
"Dynamic properties" and a bit more. 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
23 years ago
"Dynamic properties" and a bit more. 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
23 years ago
"Dynamic properties" and a bit more. 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
23 years ago
"Dynamic properties" and a bit more. 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
23 years ago
"Dynamic properties" and a bit more. 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
23 years ago
"Dynamic properties" and a bit more. 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
23 years ago
"Dynamic properties" and a bit more. 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
23 years ago
"Dynamic properties" and a bit more. 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
23 years ago
"Dynamic properties" and a bit more. 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
23 years ago
"Dynamic properties" and a bit more. 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
23 years ago
"Dynamic properties" and a bit more. 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
23 years ago
"Dynamic properties" and a bit more. 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
23 years ago
"Dynamic properties" and a bit more. 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
23 years ago
"Dynamic properties" and a bit more. 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
23 years ago
123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315316317318319320321322323324325326327328329330331332333334335336337338339340341342343344345346347348349350351352353354355356357358359360361362363364365366367368369370371372373374375376377378379380381382383384385386387388389390391392393394395396397398399400401402403404405406407408409410411412413414415416417418419420421422423424425426427428429430431432433434435436437438439440441442443444445446447448449450451452453454455456457458459460461462463464465466467468469470471472473474475476477478479480481482483484485486487488489490491492493494495496497498499500501502503504505506507508509510511512513514515516517518519520521522523524525526527528529530531532533534535536537538539540541542543544545546547548549550551552553554555556557558559560561562563564565566567568569570571572573574575576577578579580581582583584585586587588589590591592593594595596597598599600601602603604605606607608609610611612613614615616617618619620621622623624625626627628629630631632633634635636637638639640641642643644645646647648649650651652653654655656657658659660661662663664665666667668669670671672673674675676677678679680681682683684685686687688689690691692693694695696697698699700701702703704705706707708709710711712713714715716717718719720721722723724725726727728729730731732733734735736737738739740741742743744745746747748749750751752753754755756757758759760761762763764765766767768769770771772773774775776777778779780781782783784785786787788789790791792793794795796797798799800801802803804805806807808809810811812813814815816817818819820821822823824825826827828829830831832833834835836837838839840841842843844845846847848849850851852853854855856857858859860861862863864865866867868869870871872873874875876877878879880881882883884885886887888889890891892893894895896897898899900901902903904905906907908909910911912913914915916917918919920921922923924925926927928929930931932933934935936937938939940941942943944945946947948949950951952953954955956957958959960961962963964965966967968969970971972973974975976977978979980
  1. /*
  2. * Licensed to the Apache Software Foundation (ASF) under one or more
  3. * contributor license agreements. See the NOTICE file distributed with
  4. * this work for additional information regarding copyright ownership.
  5. * The ASF licenses this file to You under the Apache License, Version 2.0
  6. * (the "License"); you may not use this file except in compliance with
  7. * the License. You may obtain a copy of the License at
  8. *
  9. * http://www.apache.org/licenses/LICENSE-2.0
  10. *
  11. * Unless required by applicable law or agreed to in writing, software
  12. * distributed under the License is distributed on an "AS IS" BASIS,
  13. * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
  14. * See the License for the specific language governing permissions and
  15. * limitations under the License.
  16. *
  17. */
  18. package org.apache.tools.ant;
  19. import java.text.ParsePosition;
  20. import java.util.ArrayList;
  21. import java.util.Collections;
  22. import java.util.HashSet;
  23. import java.util.Hashtable;
  24. import java.util.Iterator;
  25. import java.util.List;
  26. import java.util.Set;
  27. import java.util.Vector;
  28. import java.util.Enumeration;
  29. import java.util.Collection;
  30. import org.apache.tools.ant.property.NullReturn;
  31. import org.apache.tools.ant.property.GetProperty;
  32. import org.apache.tools.ant.property.ParseNextProperty;
  33. import org.apache.tools.ant.property.PropertyExpander;
  34. import org.apache.tools.ant.property.ParseProperties;
  35. /* ISSUES:
  36. - ns param. It could be used to provide "namespaces" for properties, which
  37. may be more flexible.
  38. - Object value. In ant1.5 String is used for Properties - but it would be nice
  39. to support generic Objects (the property remains immutable - you can't change
  40. the associated object). This will also allow JSP-EL style setting using the
  41. Object if an attribute contains only the property (name="${property}" could
  42. avoid Object->String->Object conversion)
  43. - Currently we "chain" only for get and set property (probably most users
  44. will only need that - if they need more they can replace the top helper).
  45. Need to discuss this and find if we need more.
  46. */
  47. /* update for impending Ant 1.8:
  48. - I can't see any reason for ns and would like to deprecate it.
  49. - Replacing chaining with delegates for certain behavioral aspects.
  50. - Object value seems valuable as outlined.
  51. */
  52. /** NOT FINAL. API MAY CHANGE
  53. *
  54. * Deals with properties - substitution, dynamic properties, etc.
  55. *
  56. * This is the same code as in Ant1.5. The main addition is the ability
  57. * to chain multiple PropertyHelpers and to replace the default.
  58. *
  59. * @since Ant 1.6
  60. */
  61. public class PropertyHelper implements GetProperty {
  62. // --------------------------------------------------------
  63. //
  64. // The property delegate interfaces
  65. //
  66. // --------------------------------------------------------
  67. /**
  68. * Marker interface for a PropertyHelper delegate.
  69. * @since Ant 1.8
  70. */
  71. public interface Delegate {
  72. }
  73. /**
  74. * Describes an entity capable of evaluating a property name for value.
  75. * @since Ant 1.8
  76. */
  77. public interface PropertyEvaluator extends Delegate {
  78. /**
  79. * Evaluate a property.
  80. * @param property the property's String "identifier".
  81. * @param propertyHelper the invoking PropertyHelper.
  82. * @return Object value.
  83. */
  84. Object evaluate(String property, PropertyHelper propertyHelper);
  85. }
  86. /**
  87. * Describes an entity capable of setting a property to a value.
  88. * @since Ant 1.8
  89. */
  90. public interface PropertySetter extends Delegate {
  91. /**
  92. * Set a *new" property.
  93. * @param property the property's String "identifier".
  94. * @param value the value to set.
  95. * @param propertyHelper the invoking PropertyHelper.
  96. * @return true if this entity 'owns' the property.
  97. */
  98. boolean setNew(
  99. String property, Object value, PropertyHelper propertyHelper);
  100. /**
  101. * Set a property.
  102. * @param property the property's String "identifier".
  103. * @param value the value to set.
  104. * @param propertyHelper the invoking PropertyHelper.
  105. * @return true if this entity 'owns' the property.
  106. */
  107. boolean set(
  108. String property, Object value, PropertyHelper propertyHelper);
  109. }
  110. // --------------------------------------------------------
  111. //
  112. // The predefined property delegates
  113. //
  114. // --------------------------------------------------------
  115. private static final PropertyEvaluator TO_STRING = new PropertyEvaluator() {
  116. private String prefix = "toString:";
  117. public Object evaluate(String property, PropertyHelper propertyHelper) {
  118. Object o = null;
  119. if (property.startsWith(prefix) && propertyHelper.getProject() != null) {
  120. o = propertyHelper.getProject().getReference(property.substring(prefix.length()));
  121. }
  122. return o == null ? null : o.toString();
  123. }
  124. };
  125. private static final PropertyExpander DEFAULT_EXPANDER = new PropertyExpander() {
  126. public String parsePropertyName(
  127. String s, ParsePosition pos, ParseNextProperty notUsed) {
  128. int index = pos.getIndex();
  129. if (s.indexOf("${", index) == index) {
  130. int end = s.indexOf('}', index);
  131. if (end < 0) {
  132. throw new BuildException("Syntax error in property: " + s);
  133. }
  134. int start = index + 2;
  135. pos.setIndex(end + 1);
  136. return s.substring(start, end);
  137. }
  138. return null;
  139. }
  140. };
  141. /** dummy */
  142. private static final PropertyExpander SKIP_DOUBLE_DOLLAR
  143. = new PropertyExpander() {
  144. // CheckStyle:LineLengthCheck OFF see too long
  145. /**
  146. * {@inheritDoc}
  147. * @see org.apache.tools.ant.PropertyHelper.PropertyExpander#parsePropertyName(java.lang.String, java.text.ParsePosition, org.apache.tools.ant.PropertyHelper)
  148. */
  149. // CheckStyle:LineLengthCheck ON
  150. public String parsePropertyName(
  151. String s, ParsePosition pos, ParseNextProperty notUsed) {
  152. //System.out.println("parseproperty " + s);
  153. int index = pos.getIndex();
  154. if (s.indexOf("$$", index) == index) {
  155. pos.setIndex(++index);
  156. }
  157. return null;
  158. }
  159. };
  160. private Project project;
  161. private PropertyHelper next;
  162. private volatile Hashtable delegates = new Hashtable();
  163. /** Project properties map (usually String to String). */
  164. private Hashtable properties = new Hashtable();
  165. /**
  166. * Map of "user" properties (as created in the Ant task, for example).
  167. * Note that these key/value pairs are also always put into the
  168. * project properties, so only the project properties need to be queried.
  169. */
  170. private Hashtable userProperties = new Hashtable();
  171. /**
  172. * Map of inherited "user" properties - that are those "user"
  173. * properties that have been created by tasks and not been set
  174. * from the command line or a GUI tool.
  175. */
  176. private Hashtable inheritedProperties = new Hashtable();
  177. /**
  178. * Default constructor.
  179. */
  180. protected PropertyHelper() {
  181. add(TO_STRING);
  182. add(SKIP_DOUBLE_DOLLAR);
  183. add(DEFAULT_EXPANDER);
  184. }
  185. // --------------------------------------------------------
  186. //
  187. // Some helper static methods to get and set properties
  188. //
  189. // --------------------------------------------------------
  190. /**
  191. * A helper static method to get a property
  192. * from a particular project.
  193. * @param project the project in question.
  194. * @param name the property name
  195. * @return the value of the property if present, null otherwise.
  196. * @since Ant 1.8
  197. */
  198. public static Object getProperty(Project project, String name) {
  199. return PropertyHelper.getPropertyHelper(project)
  200. .getProperty(name);
  201. }
  202. /**
  203. * A helper static method to set a property
  204. * from a particular project.
  205. * @param project the project in question.
  206. * @param name the property name
  207. * @param value the value to use.
  208. * @since Ant 1.8
  209. */
  210. public static void setProperty(Project project, String name, Object value) {
  211. PropertyHelper.getPropertyHelper(project)
  212. .setProperty(name, value, true);
  213. }
  214. /**
  215. * A helper static method to set a new property
  216. * from a particular project.
  217. * @param project the project in question.
  218. * @param name the property name
  219. * @param value the value to use.
  220. * @since Ant 1.8
  221. */
  222. public static void setNewProperty(
  223. Project project, String name, Object value) {
  224. PropertyHelper.getPropertyHelper(project)
  225. .setNewProperty(name, value);
  226. }
  227. //override facility for subclasses to put custom hashtables in
  228. // -------------------- Hook management --------------------
  229. /**
  230. * Set the project for which this helper is performing property resolution.
  231. *
  232. * @param p the project instance.
  233. */
  234. public void setProject(Project p) {
  235. this.project = p;
  236. }
  237. /**
  238. * Get this PropertyHelper's Project.
  239. * @return Project
  240. */
  241. public Project getProject() {
  242. return project;
  243. }
  244. /**
  245. * There are 2 ways to hook into property handling:
  246. * - you can replace the main PropertyHelper. The replacement is required
  247. * to support the same semantics (of course :-)
  248. *
  249. * - you can chain a property helper capable of storing some properties.
  250. * Again, you are required to respect the immutability semantics (at
  251. * least for non-dynamic properties)
  252. *
  253. * @param next the next property helper in the chain.
  254. * @deprecated
  255. */
  256. public void setNext(PropertyHelper next) {
  257. this.next = next;
  258. }
  259. /**
  260. * Get the next property helper in the chain.
  261. *
  262. * @return the next property helper.
  263. * @deprecated
  264. */
  265. public PropertyHelper getNext() {
  266. return next;
  267. }
  268. /**
  269. * Factory method to create a property processor.
  270. * Users can provide their own or replace it using "ant.PropertyHelper"
  271. * reference. User tasks can also add themselves to the chain, and provide
  272. * dynamic properties.
  273. *
  274. * @param project the project for which the property helper is required.
  275. *
  276. * @return the project's property helper.
  277. */
  278. public static synchronized PropertyHelper getPropertyHelper(Project project) {
  279. PropertyHelper helper
  280. = (PropertyHelper) project.getReference(MagicNames.REFID_PROPERTY_HELPER);
  281. if (helper != null) {
  282. return helper;
  283. }
  284. helper = new PropertyHelper();
  285. helper.setProject(project);
  286. project.addReference(MagicNames.REFID_PROPERTY_HELPER, helper);
  287. return helper;
  288. }
  289. /**
  290. * Get the expanders.
  291. * @return the expanders.
  292. */
  293. public Collection getExpanders() {
  294. return getDelegates(PropertyExpander.class);
  295. }
  296. // -------------------- Methods to override --------------------
  297. /**
  298. * Sets a property. Any existing property of the same name
  299. * is overwritten, unless it is a user property. Will be called
  300. * from setProperty().
  301. *
  302. * If all helpers return false, the property will be saved in
  303. * the default properties table by setProperty.
  304. *
  305. * @param ns The namespace that the property is in (currently
  306. * not used.
  307. * @param name The name of property to set.
  308. * Must not be <code>null</code>.
  309. * @param value The new value of the property.
  310. * Must not be <code>null</code>.
  311. * @param inherited True if this property is inherited (an [sub]ant[call] property).
  312. * @param user True if this property is a user property.
  313. * @param isNew True is this is a new property.
  314. * @return true if this helper has stored the property, false if it
  315. * couldn't. Each helper should delegate to the next one (unless it
  316. * has a good reason not to).
  317. * @deprecated PropertyHelper chaining is deprecated.
  318. */
  319. public boolean setPropertyHook(String ns, String name,
  320. Object value,
  321. boolean inherited, boolean user,
  322. boolean isNew) {
  323. if (getNext() != null) {
  324. boolean subst = getNext().setPropertyHook(ns, name, value, inherited, user, isNew);
  325. // If next has handled the property
  326. if (subst) {
  327. return true;
  328. }
  329. }
  330. return false;
  331. }
  332. /**
  333. * Get a property. If all hooks return null, the default
  334. * tables will be used.
  335. *
  336. * @param ns namespace of the sought property.
  337. * @param name name of the sought property.
  338. * @param user True if this is a user property.
  339. * @return The property, if returned by a hook, or null if none.
  340. * @deprecated PropertyHelper chaining is deprecated.
  341. */
  342. public Object getPropertyHook(String ns, String name, boolean user) {
  343. if (getNext() != null) {
  344. Object o = getNext().getPropertyHook(ns, name, user);
  345. if (o != null) {
  346. return o;
  347. }
  348. }
  349. // Experimental/Testing, will be removed
  350. if (name.startsWith("toString:")) {
  351. name = name.substring("toString:".length());
  352. Object v = project.getReference(name);
  353. return (v == null) ? null : v.toString();
  354. }
  355. return null;
  356. }
  357. // -------------------- Optional methods --------------------
  358. // You can override those methods if you want to optimize or
  359. // do advanced things (like support a special syntax).
  360. // The methods do not chain - you should use them when embedding ant
  361. // (by replacing the main helper)
  362. /**
  363. * Parses a string containing <code>${xxx}</code> style property
  364. * references into two lists. The first list is a collection
  365. * of text fragments, while the other is a set of string property names.
  366. * <code>null</code> entries in the first list indicate a property
  367. * reference from the second list.
  368. *
  369. * It can be overridden with a more efficient or customized version.
  370. *
  371. * @param value Text to parse. Must not be <code>null</code>.
  372. * @param fragments List to add text fragments to.
  373. * Must not be <code>null</code>.
  374. * @param propertyRefs List to add property names to.
  375. * Must not be <code>null</code>.
  376. *
  377. * @exception BuildException if the string contains an opening
  378. * <code>${</code> without a closing
  379. * <code>}</code>
  380. * @deprecated We can do better than this.
  381. */
  382. public void parsePropertyString(String value, Vector fragments,
  383. Vector propertyRefs) throws BuildException {
  384. parsePropertyStringDefault(value, fragments, propertyRefs);
  385. }
  386. /**
  387. * Replaces <code>${xxx}</code> style constructions in the given value
  388. * with the string value of the corresponding data types.
  389. *
  390. * @param ns The namespace for the property.
  391. * @param value The string to be scanned for property references.
  392. * May be <code>null</code>, in which case this
  393. * method returns immediately with no effect.
  394. * @param keys Mapping (String to String) of property names to their
  395. * values. If <code>null</code>, only project properties will
  396. * be used.
  397. *
  398. * @exception BuildException if the string contains an opening
  399. * <code>${</code> without a closing
  400. * <code>}</code>
  401. * @return the original string with the properties replaced, or
  402. * <code>null</code> if the original string is <code>null</code>.
  403. */
  404. public String replaceProperties(String ns, String value, Hashtable keys) throws BuildException {
  405. return replaceProperties(value);
  406. }
  407. /**
  408. * Replaces <code>${xxx}</code> style constructions in the given value
  409. * with the string value of the corresponding data types.
  410. *
  411. * @param value The string to be scanned for property references.
  412. * May be <code>null</code>, in which case this
  413. * method returns immediately with no effect.
  414. *
  415. * @exception BuildException if the string contains an opening
  416. * <code>${</code> without a closing
  417. * <code>}</code>
  418. * @return the original string with the properties replaced, or
  419. * <code>null</code> if the original string is <code>null</code>.
  420. */
  421. public String replaceProperties(String value) throws BuildException {
  422. Object o = parseProperties(value);
  423. return o == null || o instanceof String ? (String) o : o.toString();
  424. }
  425. /**
  426. * Decode properties from a String representation. If the entire
  427. * contents of the String resolve to a single property, that value
  428. * is returned. Otherwise a String is returned.
  429. *
  430. * @param value The string to be scanned for property references.
  431. * May be <code>null</code>, in which case this
  432. * method returns immediately with no effect.
  433. *
  434. * @exception BuildException if the string contains an opening
  435. * <code>${</code> without a closing
  436. * <code>}</code>
  437. * @return the original string with the properties replaced, or
  438. * <code>null</code> if the original string is <code>null</code>.
  439. */
  440. public Object parseProperties(String value) throws BuildException {
  441. return new ParseProperties(getProject(), getExpanders(), this)
  442. .parseProperties(value);
  443. }
  444. /**
  445. * Learn whether a String contains replaceable properties.
  446. * @param value the String to check.
  447. * @return <code>true</code> if <code>value</code> contains property notation.
  448. */
  449. public boolean containsProperties(String value) {
  450. return new ParseProperties(getProject(), getExpanders(), this)
  451. .containsProperties(value);
  452. }
  453. // -------------------- Default implementation --------------------
  454. // Methods used to support the default behavior and provide backward
  455. // compatibility. Some will be deprecated, you should avoid calling them.
  456. /**
  457. * Default implementation of setProperty. Will be called from Project.
  458. * This is the original 1.5 implementation, with calls to the hook
  459. * added.
  460. * @param ns The namespace for the property (currently not used).
  461. * @param name The name of the property.
  462. * @param value The value to set the property to.
  463. * @param verbose If this is true output extra log messages.
  464. * @return true if the property is set.
  465. * @deprecated namespaces are unnecessary.
  466. */
  467. public boolean setProperty(String ns, String name, Object value, boolean verbose) {
  468. return setProperty(name, value, verbose);
  469. }
  470. /**
  471. * Default implementation of setProperty. Will be called from Project.
  472. * This is the original 1.5 implementation, with calls to the hook
  473. * added.
  474. * @param name The name of the property.
  475. * @param value The value to set the property to.
  476. * @param verbose If this is true output extra log messages.
  477. * @return true if the property is set.
  478. */
  479. public boolean setProperty(String name, Object value, boolean verbose) {
  480. for (Iterator iter = getDelegates(PropertySetter.class).iterator(); iter.hasNext();) {
  481. PropertySetter setter = (PropertySetter) iter.next();
  482. if (setter.set(name, value, this)) {
  483. return true;
  484. }
  485. }
  486. synchronized (this) {
  487. // user (CLI) properties take precedence
  488. if (userProperties.containsKey(name)) {
  489. if (verbose) {
  490. project.log("Override ignored for user property \"" + name + "\"",
  491. Project.MSG_VERBOSE);
  492. }
  493. return false;
  494. }
  495. if (verbose) {
  496. if (properties.containsKey(name)) {
  497. project.log("Overriding previous definition of property \"" + name + "\"",
  498. Project.MSG_VERBOSE);
  499. }
  500. project.log("Setting project property: " + name + " -> " + value, Project.MSG_DEBUG);
  501. }
  502. if (name != null && value != null) {
  503. properties.put(name, value);
  504. }
  505. return true;
  506. }
  507. }
  508. /**
  509. * Sets a property if no value currently exists. If the property
  510. * exists already, a message is logged and the method returns with
  511. * no other effect.
  512. *
  513. * @param ns The namespace for the property (currently not used).
  514. * @param name The name of property to set.
  515. * Must not be <code>null</code>.
  516. * @param value The new value of the property.
  517. * Must not be <code>null</code>.
  518. * @since Ant 1.6
  519. * @deprecated namespaces are unnecessary.
  520. */
  521. public void setNewProperty(String ns, String name, Object value) {
  522. setNewProperty(name, value);
  523. }
  524. /**
  525. * Sets a property if no value currently exists. If the property
  526. * exists already, a message is logged and the method returns with
  527. * no other effect.
  528. *
  529. * @param name The name of property to set.
  530. * Must not be <code>null</code>.
  531. * @param value The new value of the property.
  532. * Must not be <code>null</code>.
  533. * @since Ant 1.8
  534. */
  535. public void setNewProperty(String name, Object value) {
  536. for (Iterator iter = getDelegates(PropertySetter.class).iterator();
  537. iter.hasNext();) {
  538. PropertySetter setter = (PropertySetter) iter.next();
  539. if (setter.setNew(name, value, this)) {
  540. return;
  541. }
  542. }
  543. synchronized (this) {
  544. if (properties.containsKey(name)) {
  545. project.log("Override ignored for property \"" + name + "\"", Project.MSG_VERBOSE);
  546. return;
  547. }
  548. project.log("Setting project property: " + name + " -> " + value, Project.MSG_DEBUG);
  549. if (name != null && value != null) {
  550. properties.put(name, value);
  551. }
  552. }
  553. }
  554. /**
  555. * Sets a user property, which cannot be overwritten by
  556. * set/unset property calls. Any previous value is overwritten.
  557. * @param ns The namespace for the property (currently not used).
  558. * @param name The name of property to set.
  559. * Must not be <code>null</code>.
  560. * @param value The new value of the property.
  561. * Must not be <code>null</code>.
  562. * @deprecated namespaces are unnecessary.
  563. */
  564. public void setUserProperty(String ns, String name, Object value) {
  565. setUserProperty(name, value);
  566. }
  567. /**
  568. * Sets a user property, which cannot be overwritten by
  569. * set/unset property calls. Any previous value is overwritten.
  570. * @param name The name of property to set.
  571. * Must not be <code>null</code>.
  572. * @param value The new value of the property.
  573. * Must not be <code>null</code>.
  574. */
  575. public void setUserProperty(String name, Object value) {
  576. project.log("Setting ro project property: " + name + " -> " + value, Project.MSG_DEBUG);
  577. synchronized (this) {
  578. userProperties.put(name, value);
  579. properties.put(name, value);
  580. }
  581. }
  582. /**
  583. * Sets an inherited user property, which cannot be overwritten by set/unset
  584. * property calls. Any previous value is overwritten. Also marks
  585. * these properties as properties that have not come from the
  586. * command line.
  587. *
  588. * @param ns The namespace for the property (currently not used).
  589. * @param name The name of property to set.
  590. * Must not be <code>null</code>.
  591. * @param value The new value of the property.
  592. * Must not be <code>null</code>.
  593. * @deprecated namespaces are unnecessary.
  594. */
  595. public void setInheritedProperty(String ns, String name, Object value) {
  596. setInheritedProperty(name, value);
  597. }
  598. /**
  599. * Sets an inherited user property, which cannot be overwritten by set/unset
  600. * property calls. Any previous value is overwritten. Also marks
  601. * these properties as properties that have not come from the
  602. * command line.
  603. *
  604. * @param name The name of property to set.
  605. * Must not be <code>null</code>.
  606. * @param value The new value of the property.
  607. * Must not be <code>null</code>.
  608. */
  609. public void setInheritedProperty(String name, Object value) {
  610. project.log("Setting ro project property: " + name + " -> " + value, Project.MSG_DEBUG);
  611. synchronized (this) {
  612. inheritedProperties.put(name, value);
  613. userProperties.put(name, value);
  614. properties.put(name, value);
  615. }
  616. }
  617. // -------------------- Getting properties --------------------
  618. /**
  619. * Returns the value of a property, if it is set. You can override
  620. * this method in order to plug your own storage.
  621. *
  622. * @param ns The namespace for the property (currently not used).
  623. * @param name The name of the property.
  624. * May be <code>null</code>, in which case
  625. * the return value is also <code>null</code>.
  626. * @return the property value, or <code>null</code> for no match
  627. * or if a <code>null</code> name is provided.
  628. * @deprecated namespaces are unnecessary.
  629. */
  630. public Object getProperty(String ns, String name) {
  631. return getProperty(name);
  632. }
  633. /**
  634. * Returns the value of a property, if it is set. You can override
  635. * this method in order to plug your own storage.
  636. *
  637. * @param name The name of the property.
  638. * May be <code>null</code>, in which case
  639. * the return value is also <code>null</code>.
  640. * @return the property value, or <code>null</code> for no match
  641. * or if a <code>null</code> name is provided.
  642. */
  643. public Object getProperty(String name) {
  644. if (name == null) {
  645. return null;
  646. }
  647. for (Iterator iter = getDelegates(PropertyEvaluator.class).iterator(); iter.hasNext();) {
  648. Object o = ((PropertyEvaluator) iter.next()).evaluate(name, this);
  649. if (o != null) {
  650. if (o instanceof NullReturn) {
  651. return null;
  652. }
  653. return o;
  654. }
  655. }
  656. return properties.get(name);
  657. }
  658. /**
  659. * Returns the value of a user property, if it is set.
  660. *
  661. * @param ns The namespace for the property (currently not used).
  662. * @param name The name of the property.
  663. * May be <code>null</code>, in which case
  664. * the return value is also <code>null</code>.
  665. * @return the property value, or <code>null</code> for no match
  666. * or if a <code>null</code> name is provided.
  667. * @deprecated namespaces are unnecessary.
  668. */
  669. public Object getUserProperty(String ns, String name) {
  670. return getUserProperty(name);
  671. }
  672. /**
  673. * Returns the value of a user property, if it is set.
  674. *
  675. * @param name The name of the property.
  676. * May be <code>null</code>, in which case
  677. * the return value is also <code>null</code>.
  678. * @return the property value, or <code>null</code> for no match
  679. * or if a <code>null</code> name is provided.
  680. */
  681. public Object getUserProperty(String name) {
  682. if (name == null) {
  683. return null;
  684. }
  685. return userProperties.get(name);
  686. }
  687. // -------------------- Access to property tables --------------------
  688. // This is used to support ant call and similar tasks. It should be
  689. // deprecated, it is possible to use a better (more efficient)
  690. // mechanism to preserve the context.
  691. /**
  692. * Returns a copy of the properties table.
  693. * @return a hashtable containing all properties (including user properties).
  694. */
  695. public Hashtable getProperties() {
  696. //avoid concurrent modification:
  697. synchronized (properties) {
  698. return new Hashtable(properties);
  699. }
  700. // There is a better way to save the context. This shouldn't
  701. // delegate to next, it's for backward compatibility only.
  702. }
  703. /**
  704. * Returns a copy of the user property hashtable
  705. * @return a hashtable containing just the user properties
  706. */
  707. public Hashtable getUserProperties() {
  708. //avoid concurrent modification:
  709. synchronized (userProperties) {
  710. return new Hashtable(userProperties);
  711. }
  712. }
  713. /**
  714. * special back door for subclasses, internal access to the hashtables
  715. * @return the live hashtable of all properties
  716. */
  717. protected Hashtable getInternalProperties() {
  718. return properties;
  719. }
  720. /**
  721. * special back door for subclasses, internal access to the hashtables
  722. *
  723. * @return the live hashtable of user properties
  724. */
  725. protected Hashtable getInternalUserProperties() {
  726. return userProperties;
  727. }
  728. /**
  729. * special back door for subclasses, internal access to the hashtables
  730. *
  731. * @return the live hashtable inherited properties
  732. */
  733. protected Hashtable getInternalInheritedProperties() {
  734. return inheritedProperties;
  735. }
  736. /**
  737. * Copies all user properties that have not been set on the
  738. * command line or a GUI tool from this instance to the Project
  739. * instance given as the argument.
  740. *
  741. * <p>To copy all "user" properties, you will also have to call
  742. * {@link #copyUserProperties copyUserProperties}.</p>
  743. *
  744. * @param other the project to copy the properties to. Must not be null.
  745. *
  746. * @since Ant 1.6
  747. */
  748. public void copyInheritedProperties(Project other) {
  749. //avoid concurrent modification:
  750. synchronized (inheritedProperties) {
  751. Enumeration e = inheritedProperties.keys();
  752. while (e.hasMoreElements()) {
  753. String arg = e.nextElement().toString();
  754. if (other.getUserProperty(arg) != null) {
  755. continue;
  756. }
  757. Object value = inheritedProperties.get(arg);
  758. other.setInheritedProperty(arg, value.toString());
  759. }
  760. }
  761. }
  762. /**
  763. * Copies all user properties that have been set on the command
  764. * line or a GUI tool from this instance to the Project instance
  765. * given as the argument.
  766. *
  767. * <p>To copy all "user" properties, you will also have to call
  768. * {@link #copyInheritedProperties copyInheritedProperties}.</p>
  769. *
  770. * @param other the project to copy the properties to. Must not be null.
  771. *
  772. * @since Ant 1.6
  773. */
  774. public void copyUserProperties(Project other) {
  775. //avoid concurrent modification:
  776. synchronized (userProperties) {
  777. Enumeration e = userProperties.keys();
  778. while (e.hasMoreElements()) {
  779. Object arg = e.nextElement();
  780. if (inheritedProperties.containsKey(arg)) {
  781. continue;
  782. }
  783. Object value = userProperties.get(arg);
  784. other.setUserProperty(arg.toString(), value.toString());
  785. }
  786. }
  787. }
  788. // -------------------- Property parsing --------------------
  789. // Moved from ProjectHelper. You can override the static method -
  790. // this is used for backward compatibility (for code that calls
  791. // the parse method in ProjectHelper).
  792. /**
  793. * Default parsing method. It is here only to support backward compatibility
  794. * for the static ProjectHelper.parsePropertyString().
  795. */
  796. static void parsePropertyStringDefault(String value, Vector fragments, Vector propertyRefs)
  797. throws BuildException {
  798. int prev = 0;
  799. int pos;
  800. //search for the next instance of $ from the 'prev' position
  801. while ((pos = value.indexOf("$", prev)) >= 0) {
  802. //if there was any text before this, add it as a fragment
  803. //TODO, this check could be modified to go if pos>prev;
  804. //seems like this current version could stick empty strings
  805. //into the list
  806. if (pos > 0) {
  807. fragments.addElement(value.substring(prev, pos));
  808. }
  809. //if we are at the end of the string, we tack on a $
  810. //then move past it
  811. if (pos == (value.length() - 1)) {
  812. fragments.addElement("$");
  813. prev = pos + 1;
  814. } else if (value.charAt(pos + 1) != '{') {
  815. //peek ahead to see if the next char is a property or not
  816. //not a property: insert the char as a literal
  817. /*
  818. fragments.addElement(value.substring(pos + 1, pos + 2));
  819. prev = pos + 2;
  820. */
  821. if (value.charAt(pos + 1) == '$') {
  822. //backwards compatibility two $ map to one mode
  823. fragments.addElement("$");
  824. prev = pos + 2;
  825. } else {
  826. //new behaviour: $X maps to $X for all values of X!='$'
  827. fragments.addElement(value.substring(pos, pos + 2));
  828. prev = pos + 2;
  829. }
  830. } else {
  831. //property found, extract its name or bail on a typo
  832. int endName = value.indexOf('}', pos);
  833. if (endName < 0) {
  834. throw new BuildException("Syntax error in property: " + value);
  835. }
  836. String propertyName = value.substring(pos + 2, endName);
  837. fragments.addElement(null);
  838. propertyRefs.addElement(propertyName);
  839. prev = endName + 1;
  840. }
  841. }
  842. //no more $ signs found
  843. //if there is any tail to the file, append it
  844. if (prev < value.length()) {
  845. fragments.addElement(value.substring(prev));
  846. }
  847. }
  848. /**
  849. * Add the specified delegate object to this PropertyHelper.
  850. * Delegates are processed in LIFO order.
  851. * @param delegate the delegate to add.
  852. * @since Ant 1.8
  853. */
  854. public void add(Delegate delegate) {
  855. synchronized (Delegate.class) {
  856. Hashtable newDelegates = (Hashtable) delegates.clone();
  857. for (Iterator iter = getDelegateInterfaces(delegate).iterator(); iter.hasNext();) {
  858. Object key = iter.next();
  859. List list = (List) newDelegates.get(key);
  860. if (list == null) {
  861. list = new ArrayList();
  862. newDelegates.put(key, list);
  863. }
  864. if (list.contains(delegate)) {
  865. list.remove(delegate);
  866. }
  867. list.add(0, delegate);
  868. }
  869. delegates = newDelegates;
  870. }
  871. }
  872. /**
  873. * Get the Collection of delegates of the specified type.
  874. * @param type delegate type.
  875. * @return Collection.
  876. * @since Ant 1.8
  877. */
  878. protected List getDelegates(Class type) {
  879. Hashtable curDelegates = delegates;
  880. return curDelegates.containsKey(type)
  881. ? (List) new ArrayList((List) curDelegates.get(type))
  882. : Collections.EMPTY_LIST;
  883. }
  884. /**
  885. * Get all Delegate interfaces (excluding Delegate itself) from the specified Delegate.
  886. * @param d the Delegate to inspect.
  887. * @return Set<Class>
  888. * @since Ant 1.8
  889. */
  890. protected static Set getDelegateInterfaces(Delegate d) {
  891. HashSet result = new HashSet();
  892. Class c = d.getClass();
  893. while (c != null) {
  894. Class[] ifs = c.getInterfaces();
  895. for (int i = 0; i < ifs.length; i++) {
  896. if (Delegate.class.isAssignableFrom(ifs[i])) {
  897. result.add(ifs[i]);
  898. }
  899. }
  900. c = c.getSuperclass();
  901. }
  902. result.remove(Delegate.class);
  903. return result;
  904. }
  905. }