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 46 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
8 years ago
8 years ago
8 years ago
8 years ago
8 years ago
8 years ago
8 years ago
8 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
8 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
8 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
8 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
8 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
8 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
8 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
8 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
8 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
8 years ago
8 years ago
8 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
123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315316317318319320321322323324325326327328329330331332333334335336337338339340341342343344345346347348349350351352353354355356357358359360361362363364365366367368369370371372373374375376377378379380381382383384385386387388389390391392393394395396397398399400401402403404405406407408409410411412413414415416417418419420421422423424425426427428429430431432433434435436437438439440441442443444445446447448449450451452453454455456457458459460461462463464465466467468469470471472473474475476477478479480481482483484485486487488489490491492493494495496497498499500501502503504505506507508509510511512513514515516517518519520521522523524525526527528529530531532533534535536537538539540541542543544545546547548549550551552553554555556557558559560561562563564565566567568569570571572573574575576577578579580581582583584585586587588589590591592593594595596597598599600601602603604605606607608609610611612613614615616617618619620621622623624625626627628629630631632633634635636637638639640641642643644645646647648649650651652653654655656657658659660661662663664665666667668669670671672673674675676677678679680681682683684685686687688689690691692693694695696697698699700701702703704705706707708709710711712713714715716717718719720721722723724725726727728729730731732733734735736737738739740741742743744745746747748749750751752753754755756757758759760761762763764765766767768769770771772773774775776777778779780781782783784785786787788789790791792793794795796797798799800801802803804805806807808809810811812813814815816817818819820821822823824825826827828829830831832833834835836837838839840841842843844845846847848849850851852853854855856857858859860861862863864865866867868869870871872873874875876877878879880881882883884885886887888889890891892893894895896897898899900901902903904905906907908909910911912913914915916917918919920921922923924925926927928929930931932933934935936937938939940941942943944945946947948949950951952953954955956957958959960961962963964965966967968969970971972973974975976977978979980981982983984985986987988989990991992993994995996997998999100010011002100310041005100610071008100910101011101210131014101510161017101810191020102110221023102410251026102710281029103010311032103310341035103610371038103910401041104210431044104510461047104810491050105110521053105410551056105710581059106010611062106310641065106610671068106910701071107210731074107510761077107810791080108110821083108410851086108710881089109010911092109310941095109610971098109911001101110211031104110511061107110811091110111111121113111411151116111711181119112011211122112311241125112611271128112911301131113211331134113511361137113811391140114111421143114411451146114711481149115011511152115311541155115611571158115911601161116211631164116511661167116811691170117111721173117411751176117711781179118011811182118311841185118611871188118911901191119211931194119511961197119811991200120112021203120412051206120712081209121012111212121312141215121612171218121912201221122212231224
  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.util.ArrayList;
  20. import java.util.Collection;
  21. import java.util.Collections;
  22. import java.util.Enumeration;
  23. import java.util.HashSet;
  24. import java.util.Hashtable;
  25. import java.util.List;
  26. import java.util.Set;
  27. import java.util.Vector;
  28. import org.apache.tools.ant.property.GetProperty;
  29. import org.apache.tools.ant.property.NullReturn;
  30. import org.apache.tools.ant.property.ParseProperties;
  31. import org.apache.tools.ant.property.PropertyExpander;
  32. /* ISSUES:
  33. - ns param. It could be used to provide "namespaces" for properties, which
  34. may be more flexible.
  35. - Object value. In ant1.5 String is used for Properties - but it would be nice
  36. to support generic Objects (the property remains immutable - you can't change
  37. the associated object). This will also allow JSP-EL style setting using the
  38. Object if an attribute contains only the property (name="${property}" could
  39. avoid Object->String->Object conversion)
  40. - Currently we "chain" only for get and set property (probably most users
  41. will only need that - if they need more they can replace the top helper).
  42. Need to discuss this and find if we need more.
  43. */
  44. /* update for impending Ant 1.8.0:
  45. - I can't see any reason for ns and would like to deprecate it.
  46. - Replacing chaining with delegates for certain behavioral aspects.
  47. - Object value seems valuable as outlined.
  48. */
  49. /**
  50. * Deals with properties - substitution, dynamic properties, etc.
  51. *
  52. * <p>This code has been heavily restructured for Ant 1.8.0. It is
  53. * expected that custom PropertyHelper implementation that used the
  54. * older chaining mechanism of Ant 1.6 won't work in all cases, and
  55. * its usage is deprecated. The preferred way to customize Ant's
  56. * property handling is by {@link #add adding} {@link
  57. * PropertyHelper.Delegate delegates} of the appropriate subinterface
  58. * and have this implementation use them.</p>
  59. *
  60. * <p>When {@link #parseProperties expanding a string that may contain
  61. * properties} this class will delegate the actual parsing to {@link
  62. * org.apache.tools.ant.property.ParseProperties#parseProperties
  63. * parseProperties} inside the ParseProperties class which in turn
  64. * uses the {@link org.apache.tools.ant.property.PropertyExpander
  65. * PropertyExpander delegates} to find properties inside the string
  66. * and this class to expand the property names found into the
  67. * corresponding values.</p>
  68. *
  69. * <p>When {@link #getProperty looking up a property value} this class
  70. * will first consult all {@link PropertyHelper.PropertyEvaluator
  71. * PropertyEvaluator} delegates and fall back to an internal map of
  72. * "project properties" if no evaluator matched the property name.</p>
  73. *
  74. * <p>When {@link #setProperty setting a property value} this class
  75. * will first consult all {@link PropertyHelper.PropertySetter
  76. * PropertySetter} delegates and fall back to an internal map of
  77. * "project properties" if no setter matched the property name.</p>
  78. *
  79. * @since Ant 1.6
  80. */
  81. public class PropertyHelper implements GetProperty {
  82. // --------------------------------------------------------
  83. //
  84. // The property delegate interfaces
  85. //
  86. // --------------------------------------------------------
  87. /**
  88. * Marker interface for a PropertyHelper delegate.
  89. * @since Ant 1.8.0
  90. */
  91. public interface Delegate {
  92. }
  93. /**
  94. * Looks up a property's value based on its name.
  95. *
  96. * <p>Can be used to look up properties in a different storage
  97. * than the project instance (like local properties for example)
  98. * or to implement custom "protocols" like Ant's
  99. * <code>${toString:refid}</code> syntax.</p>
  100. *
  101. * @since Ant 1.8.0
  102. */
  103. public interface PropertyEvaluator extends Delegate {
  104. /**
  105. * Evaluate a property.
  106. *
  107. * @param property the property's String "identifier".
  108. * @param propertyHelper the invoking PropertyHelper.
  109. * @return null if the property name could not be found, an
  110. * instance of {@link org.apache.tools.ant.property.NullReturn
  111. * NullReturn} to indicate a property with a name that can be
  112. * matched but a value of <code>null</code> and the property's
  113. * value otherwise.
  114. */
  115. Object evaluate(String property, PropertyHelper propertyHelper);
  116. }
  117. /**
  118. * Sets or overrides a property.
  119. *
  120. * <p>Can be used to store properties in a different storage than
  121. * the project instance (like local properties for example).</p>
  122. *
  123. * @since Ant 1.8.0
  124. */
  125. public interface PropertySetter extends Delegate {
  126. /**
  127. * Set a *new" property.
  128. *
  129. * <p>Should not replace the value of an existing property.</p>
  130. *
  131. * @param property the property's String "identifier".
  132. * @param value the value to set.
  133. * @param propertyHelper the invoking PropertyHelper.
  134. * @return true if this entity 'owns' the property.
  135. */
  136. boolean setNew(
  137. String property, Object value, PropertyHelper propertyHelper);
  138. /**
  139. * Set a property.
  140. *
  141. * <p>May replace the value of an existing property.</p>
  142. *
  143. * @param property the property's String "identifier".
  144. * @param value the value to set.
  145. * @param propertyHelper the invoking PropertyHelper.
  146. * @return true if this entity 'owns' the property.
  147. */
  148. boolean set(
  149. String property, Object value, PropertyHelper propertyHelper);
  150. }
  151. //TODO PropertyEnumerator Delegate type, would improve PropertySet
  152. // --------------------------------------------------------
  153. //
  154. // The predefined property delegates
  155. //
  156. // --------------------------------------------------------
  157. private static final PropertyEvaluator TO_STRING = new PropertyEvaluator() {
  158. private final String PREFIX = "toString:";
  159. private final int PREFIX_LEN = PREFIX.length();
  160. public Object evaluate(String property, PropertyHelper propertyHelper) {
  161. Object o = null;
  162. if (property.startsWith(PREFIX) && propertyHelper.getProject() != null) {
  163. o = propertyHelper.getProject().getReference(property.substring(PREFIX_LEN));
  164. }
  165. return o == null ? null : o.toString();
  166. }
  167. };
  168. private static final PropertyExpander DEFAULT_EXPANDER =
  169. (s, pos, notUsed) -> {
  170. int index = pos.getIndex();
  171. //directly check near, triggering characters:
  172. if (s.length() - index >= 3 && '$' == s.charAt(index)
  173. && '{' == s.charAt(index + 1)) {
  174. int start = index + 2;
  175. //defer to String.indexOf() for protracted check:
  176. int end = s.indexOf('}', start);
  177. if (end < 0) {
  178. throw new BuildException(
  179. "Syntax error in property: " + s.substring(index));
  180. }
  181. pos.setIndex(end + 1);
  182. return start == end ? "" : s.substring(start, end);
  183. }
  184. return null;
  185. };
  186. /** dummy */
  187. private static final PropertyExpander SKIP_DOUBLE_DOLLAR =
  188. (s, pos, notUsed) -> {
  189. int index = pos.getIndex();
  190. if (s.length() - index >= 2) {
  191. /* check for $$; if found, advance by one--
  192. * this expander is at the bottom of the stack
  193. * and will thus be the last consulted,
  194. * so the next thing that ParseProperties will do
  195. * is advance the parse position beyond the second $
  196. */
  197. if ('$' == s.charAt(index) && '$' == s.charAt(++index)) {
  198. pos.setIndex(index);
  199. }
  200. }
  201. return null;
  202. };
  203. /**
  204. * @since Ant 1.8.0
  205. */
  206. private static final PropertyEvaluator FROM_REF = new PropertyEvaluator() {
  207. private final String PREFIX = "ant.refid:";
  208. private final int PREFIX_LEN = PREFIX.length();
  209. public Object evaluate(String prop, PropertyHelper helper) {
  210. return prop.startsWith(PREFIX) && helper.getProject() != null
  211. ? helper.getProject().getReference(prop.substring(PREFIX_LEN))
  212. : null;
  213. }
  214. };
  215. private Project project;
  216. private PropertyHelper next;
  217. private final Hashtable<Class<? extends Delegate>, List<Delegate>> delegates = new Hashtable<>();
  218. /** Project properties map (usually String to String). */
  219. private Hashtable<String, Object> properties = new Hashtable<>();
  220. /**
  221. * Map of "user" properties (as created in the Ant task, for example).
  222. * Note that these key/value pairs are also always put into the
  223. * project properties, so only the project properties need to be queried.
  224. */
  225. private Hashtable<String, Object> userProperties = new Hashtable<>();
  226. /**
  227. * Map of inherited "user" properties - that are those "user"
  228. * properties that have been created by tasks and not been set
  229. * from the command line or a GUI tool.
  230. */
  231. private Hashtable<String, Object> inheritedProperties = new Hashtable<>();
  232. /**
  233. * Default constructor.
  234. */
  235. protected PropertyHelper() {
  236. add(FROM_REF);
  237. add(TO_STRING);
  238. add(SKIP_DOUBLE_DOLLAR);
  239. add(DEFAULT_EXPANDER);
  240. }
  241. // --------------------------------------------------------
  242. //
  243. // Some helper static methods to get and set properties
  244. //
  245. // --------------------------------------------------------
  246. /**
  247. * A helper static method to get a property
  248. * from a particular project.
  249. * @param project the project in question.
  250. * @param name the property name
  251. * @return the value of the property if present, null otherwise.
  252. * @since Ant 1.8.0
  253. */
  254. public static Object getProperty(Project project, String name) {
  255. return PropertyHelper.getPropertyHelper(project)
  256. .getProperty(name);
  257. }
  258. /**
  259. * A helper static method to set a property
  260. * from a particular project.
  261. * @param project the project in question.
  262. * @param name the property name
  263. * @param value the value to use.
  264. * @since Ant 1.8.0
  265. */
  266. public static void setProperty(Project project, String name, Object value) {
  267. PropertyHelper.getPropertyHelper(project)
  268. .setProperty(name, value, true);
  269. }
  270. /**
  271. * A helper static method to set a new property
  272. * from a particular project.
  273. * @param project the project in question.
  274. * @param name the property name
  275. * @param value the value to use.
  276. * @since Ant 1.8.0
  277. */
  278. public static void setNewProperty(
  279. Project project, String name, Object value) {
  280. PropertyHelper.getPropertyHelper(project)
  281. .setNewProperty(name, value);
  282. }
  283. //override facility for subclasses to put custom hashtables in
  284. // -------------------- Hook management --------------------
  285. /**
  286. * Set the project for which this helper is performing property resolution.
  287. *
  288. * @param p the project instance.
  289. */
  290. public void setProject(Project p) {
  291. this.project = p;
  292. }
  293. /**
  294. * Get this PropertyHelper's Project.
  295. * @return Project
  296. */
  297. public Project getProject() {
  298. return project;
  299. }
  300. /**
  301. * Prior to Ant 1.8.0 there have been 2 ways to hook into property handling:
  302. *
  303. * - you can replace the main PropertyHelper. The replacement is required
  304. * to support the same semantics (of course :-)
  305. *
  306. * - you can chain a property helper capable of storing some properties.
  307. * Again, you are required to respect the immutability semantics (at
  308. * least for non-dynamic properties)
  309. *
  310. * <p>As of Ant 1.8.0 this method is never invoked by any code
  311. * inside of Ant itself.</p>
  312. *
  313. * @param next the next property helper in the chain.
  314. * @deprecated use the delegate mechanism instead
  315. */
  316. @Deprecated
  317. public void setNext(PropertyHelper next) {
  318. this.next = next;
  319. }
  320. /**
  321. * Get the next property helper in the chain.
  322. *
  323. * <p>As of Ant 1.8.0 this method is never invoked by any code
  324. * inside of Ant itself except the {@link #setPropertyHook
  325. * setPropertyHook} and {@link #getPropertyHook getPropertyHook}
  326. * methods in this class.</p>
  327. *
  328. * @return the next property helper.
  329. * @deprecated use the delegate mechanism instead
  330. */
  331. @Deprecated
  332. public PropertyHelper getNext() {
  333. return next;
  334. }
  335. /**
  336. * Factory method to create a property processor.
  337. * Users can provide their own or replace it using "ant.PropertyHelper"
  338. * reference. User tasks can also add themselves to the chain, and provide
  339. * dynamic properties.
  340. *
  341. * @param project the project for which the property helper is required.
  342. *
  343. * @return the project's property helper.
  344. */
  345. public static synchronized PropertyHelper getPropertyHelper(Project project) {
  346. PropertyHelper helper = null;
  347. if (project != null) {
  348. helper = (PropertyHelper) project.getReference(MagicNames
  349. .REFID_PROPERTY_HELPER);
  350. }
  351. if (helper != null) {
  352. return helper;
  353. }
  354. helper = new PropertyHelper();
  355. helper.setProject(project);
  356. if (project != null) {
  357. project.addReference(MagicNames.REFID_PROPERTY_HELPER, helper);
  358. }
  359. return helper;
  360. }
  361. /**
  362. * Get the {@link PropertyExpander expanders}.
  363. * @since Ant 1.8.0
  364. * @return the expanders.
  365. */
  366. public Collection<PropertyExpander> getExpanders() {
  367. return getDelegates(PropertyExpander.class);
  368. }
  369. // -------------------- Methods to override --------------------
  370. /**
  371. * Sets a property. Any existing property of the same name
  372. * is overwritten, unless it is a user property.
  373. *
  374. * If all helpers return false, the property will be saved in
  375. * the default properties table by setProperty.
  376. *
  377. * <p>As of Ant 1.8.0 this method is never invoked by any code
  378. * inside of Ant itself.</p>
  379. *
  380. * @param ns The namespace that the property is in (currently
  381. * not used.
  382. * @param name The name of property to set.
  383. * Must not be <code>null</code>.
  384. * @param value The new value of the property.
  385. * Must not be <code>null</code>.
  386. * @param inherited True if this property is inherited (an [sub]ant[call] property).
  387. * @param user True if this property is a user property.
  388. * @param isNew True is this is a new property.
  389. * @return true if this helper has stored the property, false if it
  390. * couldn't. Each helper should delegate to the next one (unless it
  391. * has a good reason not to).
  392. * @deprecated PropertyHelper chaining is deprecated.
  393. */
  394. @Deprecated
  395. public boolean setPropertyHook(String ns, String name,
  396. Object value,
  397. boolean inherited, boolean user,
  398. boolean isNew) {
  399. if (getNext() != null) {
  400. boolean subst = getNext().setPropertyHook(ns, name, value, inherited, user, isNew);
  401. // If next has handled the property
  402. if (subst) {
  403. return true;
  404. }
  405. }
  406. return false;
  407. }
  408. /**
  409. * Get a property. If all hooks return null, the default
  410. * tables will be used.
  411. *
  412. * <p>As of Ant 1.8.0 this method is never invoked by any code
  413. * inside of Ant itself.</p>
  414. *
  415. * @param ns namespace of the sought property.
  416. * @param name name of the sought property.
  417. * @param user True if this is a user property.
  418. * @return The property, if returned by a hook, or null if none.
  419. * @deprecated PropertyHelper chaining is deprecated.
  420. */
  421. @Deprecated
  422. public Object getPropertyHook(String ns, String name, boolean user) {
  423. if (getNext() != null) {
  424. Object o = getNext().getPropertyHook(ns, name, user);
  425. if (o != null) {
  426. return o;
  427. }
  428. }
  429. // Experimental/Testing, will be removed
  430. if (project != null && name.startsWith("toString:")) {
  431. name = name.substring("toString:".length());
  432. Object v = project.getReference(name);
  433. return (v == null) ? null : v.toString();
  434. }
  435. return null;
  436. }
  437. // -------------------- Optional methods --------------------
  438. // You can override those methods if you want to optimize or
  439. // do advanced things (like support a special syntax).
  440. // The methods do not chain - you should use them when embedding ant
  441. // (by replacing the main helper)
  442. /**
  443. * Parses a string containing <code>${xxx}</code> style property
  444. * references into two lists. The first list is a collection
  445. * of text fragments, while the other is a set of string property names.
  446. * <code>null</code> entries in the first list indicate a property
  447. * reference from the second list.
  448. *
  449. * <p>Delegates to {@link #parsePropertyStringDefault
  450. * parsePropertyStringDefault}.</p>
  451. *
  452. * <p>As of Ant 1.8.0 this method is never invoked by any code
  453. * inside of Ant itself except {ProjectHelper#parsePropertyString
  454. * ProjectHelper.parsePropertyString}.</p>
  455. *
  456. * @param value Text to parse. Must not be <code>null</code>.
  457. * @param fragments List to add text fragments to.
  458. * Must not be <code>null</code>.
  459. * @param propertyRefs List to add property names to.
  460. * Must not be <code>null</code>.
  461. *
  462. * @exception BuildException if the string contains an opening
  463. * <code>${</code> without a closing
  464. * <code>}</code>
  465. * @deprecated use the other mechanisms of this class instead
  466. */
  467. @Deprecated
  468. public void parsePropertyString(String value, Vector<String> fragments,
  469. Vector<String> propertyRefs) throws BuildException {
  470. parsePropertyStringDefault(value, fragments, propertyRefs);
  471. }
  472. /**
  473. * Replaces <code>${xxx}</code> style constructions in the given value
  474. * with the string value of the corresponding data types.
  475. *
  476. * <p>Delegates to the one-arg version, completely ignoring the ns
  477. * and keys parameters.</p>
  478. *
  479. * @param ns The namespace for the property.
  480. * @param value The string to be scanned for property references.
  481. * May be <code>null</code>, in which case this
  482. * method returns immediately with no effect.
  483. * @param keys Mapping (String to Object) of property names to their
  484. * values. If <code>null</code>, only project properties will
  485. * be used.
  486. *
  487. * @exception BuildException if the string contains an opening
  488. * <code>${</code> without a closing
  489. * <code>}</code>
  490. * @return the original string with the properties replaced, or
  491. * <code>null</code> if the original string is <code>null</code>.
  492. */
  493. //TODO deprecate? Recall why no longer using ns/keys params
  494. public String replaceProperties(String ns, String value, Hashtable<String, Object> keys) throws BuildException {
  495. return replaceProperties(value);
  496. }
  497. /**
  498. * Replaces <code>${xxx}</code> style constructions in the given value
  499. * with the string value of the corresponding data types.
  500. *
  501. * @param value The string to be scanned for property references.
  502. * May be <code>null</code>, in which case this
  503. * method returns immediately with no effect.
  504. *
  505. * @exception BuildException if the string contains an opening
  506. * <code>${</code> without a closing
  507. * <code>}</code>
  508. * @return the original string with the properties replaced, or
  509. * <code>null</code> if the original string is <code>null</code>.
  510. */
  511. public String replaceProperties(String value) throws BuildException {
  512. Object o = parseProperties(value);
  513. return o == null || o instanceof String ? (String) o : o.toString();
  514. }
  515. /**
  516. * Decode properties from a String representation. If the entire
  517. * contents of the String resolve to a single property, that value
  518. * is returned. Otherwise a String is returned.
  519. *
  520. * @param value The string to be scanned for property references.
  521. * May be <code>null</code>, in which case this
  522. * method returns immediately with no effect.
  523. *
  524. * @exception BuildException if the string contains an opening
  525. * <code>${</code> without a closing
  526. * <code>}</code>
  527. * @return the original string with the properties replaced, or
  528. * <code>null</code> if the original string is <code>null</code>.
  529. */
  530. public Object parseProperties(String value) throws BuildException {
  531. return new ParseProperties(getProject(), getExpanders(), this)
  532. .parseProperties(value);
  533. }
  534. /**
  535. * Learn whether a String contains replaceable properties.
  536. * @param value the String to check.
  537. * @return <code>true</code> if <code>value</code> contains property notation.
  538. */
  539. public boolean containsProperties(String value) {
  540. return new ParseProperties(getProject(), getExpanders(), this)
  541. .containsProperties(value);
  542. }
  543. // -------------------- Default implementation --------------------
  544. // Methods used to support the default behavior and provide backward
  545. // compatibility. Some will be deprecated, you should avoid calling them.
  546. /**
  547. * Default implementation of setProperty. Will be called from Project.
  548. * This is the original 1.5 implementation, with calls to the hook
  549. * added.
  550. *
  551. * <p>Delegates to the three-arg version, completely ignoring the
  552. * ns parameter.</p>
  553. *
  554. * @param ns The namespace for the property (currently not used).
  555. * @param name The name of the property.
  556. * @param value The value to set the property to.
  557. * @param verbose If this is true output extra log messages.
  558. * @return true if the property is set.
  559. * @deprecated namespaces are unnecessary.
  560. */
  561. @Deprecated
  562. public boolean setProperty(String ns, String name, Object value, boolean verbose) {
  563. return setProperty(name, value, verbose);
  564. }
  565. /**
  566. * Default implementation of setProperty. Will be called from Project.
  567. * @param name The name of the property.
  568. * @param value The value to set the property to.
  569. * @param verbose If this is true output extra log messages.
  570. * @return true if the property is set.
  571. */
  572. public boolean setProperty(String name, Object value, boolean verbose) {
  573. for (PropertySetter setter : getDelegates(PropertySetter.class)) {
  574. if (setter.set(name, value, this)) {
  575. return true;
  576. }
  577. }
  578. synchronized (this) {
  579. // user (CLI) properties take precedence
  580. if (userProperties.containsKey(name)) {
  581. if (project != null && verbose) {
  582. project.log("Override ignored for user property \""
  583. + name + "\"", Project.MSG_VERBOSE);
  584. }
  585. return false;
  586. }
  587. if (project != null && verbose) {
  588. if (properties.containsKey(name)) {
  589. project.log("Overriding previous definition of property \""
  590. + name + "\"", Project.MSG_VERBOSE);
  591. }
  592. project.log("Setting project property: " + name + " -> "
  593. + value, Project.MSG_DEBUG);
  594. }
  595. if (name != null && value != null) {
  596. properties.put(name, value);
  597. }
  598. return true;
  599. }
  600. }
  601. /**
  602. * Sets a property if no value currently exists. If the property
  603. * exists already, a message is logged and the method returns with
  604. * no other effect.
  605. *
  606. * <p>Delegates to the two-arg version, completely ignoring the
  607. * ns parameter.</p>
  608. *
  609. * @param ns The namespace for the property (currently not used).
  610. * @param name The name of property to set.
  611. * Must not be <code>null</code>.
  612. * @param value The new value of the property.
  613. * Must not be <code>null</code>.
  614. * @since Ant 1.6
  615. * @deprecated namespaces are unnecessary.
  616. */
  617. @Deprecated
  618. public void setNewProperty(String ns, String name, Object value) {
  619. setNewProperty(name, value);
  620. }
  621. /**
  622. * Sets a property if no value currently exists. If the property
  623. * exists already, a message is logged and the method returns with
  624. * no other effect.
  625. *
  626. * @param name The name of property to set.
  627. * Must not be <code>null</code>.
  628. * @param value The new value of the property.
  629. * Must not be <code>null</code>.
  630. * @since Ant 1.8.0
  631. */
  632. public void setNewProperty(String name, Object value) {
  633. for (PropertySetter setter : getDelegates(PropertySetter.class)) {
  634. if (setter.setNew(name, value, this)) {
  635. return;
  636. }
  637. }
  638. synchronized (this) {
  639. if (project != null && properties.containsKey(name)) {
  640. project.log("Override ignored for property \"" + name
  641. + "\"", Project.MSG_VERBOSE);
  642. return;
  643. }
  644. if (project != null) {
  645. project.log("Setting project property: " + name
  646. + " -> " + value, Project.MSG_DEBUG);
  647. }
  648. if (name != null && value != null) {
  649. properties.put(name, value);
  650. }
  651. }
  652. }
  653. /**
  654. * Sets a user property, which cannot be overwritten by
  655. * set/unset property calls. Any previous value is overwritten.
  656. *
  657. * <p>Delegates to the two-arg version, completely ignoring the
  658. * ns parameter.</p>
  659. *
  660. * @param ns The namespace for the property (currently not used).
  661. * @param name The name of property to set.
  662. * Must not be <code>null</code>.
  663. * @param value The new value of the property.
  664. * Must not be <code>null</code>.
  665. * @deprecated namespaces are unnecessary.
  666. */
  667. @Deprecated
  668. public void setUserProperty(String ns, String name, Object value) {
  669. setUserProperty(name, value);
  670. }
  671. /**
  672. * Sets a user property, which cannot be overwritten by
  673. * set/unset property calls. Any previous value is overwritten.
  674. *
  675. * <p>Does <code>not</code> consult any delegates.</p>
  676. *
  677. * @param name The name of property to set.
  678. * Must not be <code>null</code>.
  679. * @param value The new value of the property.
  680. * Must not be <code>null</code>.
  681. */
  682. public void setUserProperty(String name, Object value) {
  683. if (project != null) {
  684. project.log("Setting ro project property: "
  685. + name + " -> " + value, Project.MSG_DEBUG);
  686. }
  687. synchronized (this) {
  688. userProperties.put(name, value);
  689. properties.put(name, value);
  690. }
  691. }
  692. /**
  693. * Sets an inherited user property, which cannot be overwritten by set/unset
  694. * property calls. Any previous value is overwritten. Also marks
  695. * these properties as properties that have not come from the
  696. * command line.
  697. *
  698. * <p>Delegates to the two-arg version, completely ignoring the
  699. * ns parameter.</p>
  700. *
  701. * @param ns The namespace for the property (currently not used).
  702. * @param name The name of property to set.
  703. * Must not be <code>null</code>.
  704. * @param value The new value of the property.
  705. * Must not be <code>null</code>.
  706. * @deprecated namespaces are unnecessary.
  707. */
  708. @Deprecated
  709. public void setInheritedProperty(String ns, String name, Object value) {
  710. setInheritedProperty(name, value);
  711. }
  712. /**
  713. * Sets an inherited user property, which cannot be overwritten by set/unset
  714. * property calls. Any previous value is overwritten. Also marks
  715. * these properties as properties that have not come from the
  716. * command line.
  717. *
  718. * <p>Does <code>not</code> consult any delegates.</p>
  719. *
  720. * @param name The name of property to set.
  721. * Must not be <code>null</code>.
  722. * @param value The new value of the property.
  723. * Must not be <code>null</code>.
  724. */
  725. public void setInheritedProperty(String name, Object value) {
  726. if (project != null) {
  727. project.log("Setting ro project property: " + name + " -> "
  728. + value, Project.MSG_DEBUG);
  729. }
  730. synchronized (this) {
  731. inheritedProperties.put(name, value);
  732. userProperties.put(name, value);
  733. properties.put(name, value);
  734. }
  735. }
  736. // -------------------- Getting properties --------------------
  737. /**
  738. * Returns the value of a property, if it is set. You can override
  739. * this method in order to plug your own storage.
  740. *
  741. * <p>Delegates to the one-arg version ignoring the ns parameter.</p>
  742. *
  743. * @param ns The namespace for the property (currently not used).
  744. * @param name The name of the property.
  745. * May be <code>null</code>, in which case
  746. * the return value is also <code>null</code>.
  747. * @return the property value, or <code>null</code> for no match
  748. * or if a <code>null</code> name is provided.
  749. * @deprecated namespaces are unnecessary.
  750. */
  751. @Deprecated
  752. public Object getProperty(String ns, String name) {
  753. return getProperty(name);
  754. }
  755. /**
  756. * Returns the value of a property, if it is set.
  757. *
  758. * <p>This is the method that is invoked by {Project#getProperty
  759. * Project.getProperty}.</p>
  760. *
  761. * <p>You can override this method in order to plug your own
  762. * storage but the recommended approach is to add your own
  763. * implementation of {@link PropertyEvaluator PropertyEvaluator}
  764. * instead.</p>
  765. *
  766. * @param name The name of the property.
  767. * May be <code>null</code>, in which case
  768. * the return value is also <code>null</code>.
  769. * @return the property value, or <code>null</code> for no match
  770. * or if a <code>null</code> name is provided.
  771. */
  772. public Object getProperty(String name) {
  773. if (name == null) {
  774. return null;
  775. }
  776. for (PropertyEvaluator evaluator : getDelegates(PropertyEvaluator.class)) {
  777. final Object o = evaluator.evaluate(name, this);
  778. if (o == null) {
  779. continue;
  780. }
  781. return o instanceof NullReturn ? null : o;
  782. }
  783. return properties.get(name);
  784. }
  785. /**
  786. * Returns the value of a user property, if it is set.
  787. *
  788. * <p>Delegates to the one-arg version ignoring the ns parameter.</p>
  789. *
  790. * @param ns The namespace for the property (currently not used).
  791. * @param name The name of the property.
  792. * May be <code>null</code>, in which case
  793. * the return value is also <code>null</code>.
  794. * @return the property value, or <code>null</code> for no match
  795. * or if a <code>null</code> name is provided.
  796. * @deprecated namespaces are unnecessary.
  797. */
  798. @Deprecated
  799. public Object getUserProperty(String ns, String name) {
  800. return getUserProperty(name);
  801. }
  802. /**
  803. * Returns the value of a user property, if it is set.
  804. *
  805. * <p>Does <code>not</code> consult any delegates.</p>
  806. *
  807. * @param name The name of the property.
  808. * May be <code>null</code>, in which case
  809. * the return value is also <code>null</code>.
  810. * @return the property value, or <code>null</code> for no match
  811. * or if a <code>null</code> name is provided.
  812. */
  813. public Object getUserProperty(String name) {
  814. if (name == null) {
  815. return null;
  816. }
  817. return userProperties.get(name);
  818. }
  819. // -------------------- Access to property tables --------------------
  820. // This is used to support ant call and similar tasks. It should be
  821. // deprecated, it is possible to use a better (more efficient)
  822. // mechanism to preserve the context.
  823. /**
  824. * Returns a copy of the properties table.
  825. *
  826. * <p>Does not contain properties held by implementations of
  827. * delegates (like local properties).</p>
  828. *
  829. * @return a hashtable containing all properties (including user properties).
  830. */
  831. public Hashtable<String, Object> getProperties() {
  832. //avoid concurrent modification:
  833. synchronized (properties) {
  834. return new Hashtable<>(properties);
  835. }
  836. // There is a better way to save the context. This shouldn't
  837. // delegate to next, it's for backward compatibility only.
  838. }
  839. /**
  840. * Returns a copy of the user property hashtable
  841. *
  842. * <p>Does not contain properties held by implementations of
  843. * delegates (like local properties).</p>
  844. *
  845. * @return a hashtable containing just the user properties
  846. */
  847. public Hashtable<String, Object> getUserProperties() {
  848. //avoid concurrent modification:
  849. synchronized (userProperties) {
  850. return new Hashtable<>(userProperties);
  851. }
  852. }
  853. /**
  854. * Returns a copy of the inherited property hashtable
  855. *
  856. * <p>Does not contain properties held by implementations of
  857. * delegates (like local properties).</p>
  858. *
  859. * @return a hashtable containing just the inherited properties
  860. */
  861. public Hashtable<String, Object> getInheritedProperties() {
  862. //avoid concurrent modification:
  863. synchronized (inheritedProperties) {
  864. return new Hashtable<>(inheritedProperties);
  865. }
  866. }
  867. /**
  868. * special back door for subclasses, internal access to the hashtables
  869. * @return the live hashtable of all properties
  870. */
  871. protected Hashtable<String, Object> getInternalProperties() {
  872. return properties;
  873. }
  874. /**
  875. * special back door for subclasses, internal access to the hashtables
  876. *
  877. * @return the live hashtable of user properties
  878. */
  879. protected Hashtable<String, Object> getInternalUserProperties() {
  880. return userProperties;
  881. }
  882. /**
  883. * special back door for subclasses, internal access to the hashtables
  884. *
  885. * @return the live hashtable inherited properties
  886. */
  887. protected Hashtable<String, Object> getInternalInheritedProperties() {
  888. return inheritedProperties;
  889. }
  890. /**
  891. * Copies all user properties that have not been set on the
  892. * command line or a GUI tool from this instance to the Project
  893. * instance given as the argument.
  894. *
  895. * <p>To copy all "user" properties, you will also have to call
  896. * {@link #copyUserProperties copyUserProperties}.</p>
  897. *
  898. * <p>Does not copy properties held by implementations of
  899. * delegates (like local properties).</p>
  900. *
  901. * @param other the project to copy the properties to. Must not be null.
  902. *
  903. * @since Ant 1.6
  904. */
  905. public void copyInheritedProperties(Project other) {
  906. //avoid concurrent modification:
  907. synchronized (inheritedProperties) {
  908. Enumeration<String> e = inheritedProperties.keys();
  909. while (e.hasMoreElements()) {
  910. String arg = e.nextElement();
  911. if (other.getUserProperty(arg) != null) {
  912. continue;
  913. }
  914. Object value = inheritedProperties.get(arg);
  915. other.setInheritedProperty(arg, value.toString());
  916. }
  917. }
  918. }
  919. /**
  920. * Copies all user properties that have been set on the command
  921. * line or a GUI tool from this instance to the Project instance
  922. * given as the argument.
  923. *
  924. * <p>To copy all "user" properties, you will also have to call
  925. * {@link #copyInheritedProperties copyInheritedProperties}.</p>
  926. *
  927. * <p>Does not copy properties held by implementations of
  928. * delegates (like local properties).</p>
  929. *
  930. * @param other the project to copy the properties to. Must not be null.
  931. *
  932. * @since Ant 1.6
  933. */
  934. public void copyUserProperties(Project other) {
  935. //avoid concurrent modification:
  936. synchronized (userProperties) {
  937. Enumeration<String> e = userProperties.keys();
  938. while (e.hasMoreElements()) {
  939. Object arg = e.nextElement();
  940. if (inheritedProperties.containsKey(arg)) {
  941. continue;
  942. }
  943. Object value = userProperties.get(arg);
  944. other.setUserProperty(arg.toString(), value.toString());
  945. }
  946. }
  947. }
  948. // -------------------- Property parsing --------------------
  949. // Moved from ProjectHelper. You can override the static method -
  950. // this is used for backward compatibility (for code that calls
  951. // the parse method in ProjectHelper).
  952. /**
  953. * Default parsing method. It is here only to support backward compatibility
  954. * for the static ProjectHelper.parsePropertyString().
  955. */
  956. static void parsePropertyStringDefault(String value, Vector<String> fragments, Vector<String> propertyRefs)
  957. throws BuildException {
  958. int prev = 0;
  959. int pos;
  960. //search for the next instance of $ from the 'prev' position
  961. while ((pos = value.indexOf('$', prev)) >= 0) {
  962. //if there was any text before this, add it as a fragment
  963. //TODO, this check could be modified to go if pos>prev;
  964. //seems like this current version could stick empty strings
  965. //into the list
  966. if (pos > 0) {
  967. fragments.addElement(value.substring(prev, pos));
  968. }
  969. //if we are at the end of the string, we tack on a $
  970. //then move past it
  971. if (pos == (value.length() - 1)) {
  972. fragments.addElement("$");
  973. prev = pos + 1;
  974. } else if (value.charAt(pos + 1) != '{') {
  975. //peek ahead to see if the next char is a property or not
  976. //not a property: insert the char as a literal
  977. /*
  978. fragments.addElement(value.substring(pos + 1, pos + 2));
  979. prev = pos + 2;
  980. */
  981. if (value.charAt(pos + 1) == '$') {
  982. //backwards compatibility two $ map to one mode
  983. fragments.addElement("$");
  984. prev = pos + 2;
  985. } else {
  986. //new behaviour: $X maps to $X for all values of X!='$'
  987. fragments.addElement(value.substring(pos, pos + 2));
  988. prev = pos + 2;
  989. }
  990. } else {
  991. //property found, extract its name or bail on a typo
  992. int endName = value.indexOf('}', pos);
  993. if (endName < 0) {
  994. throw new BuildException("Syntax error in property: " + value);
  995. }
  996. String propertyName = value.substring(pos + 2, endName);
  997. fragments.addElement(null);
  998. propertyRefs.addElement(propertyName);
  999. prev = endName + 1;
  1000. }
  1001. }
  1002. //no more $ signs found
  1003. //if there is any tail to the file, append it
  1004. if (prev < value.length()) {
  1005. fragments.addElement(value.substring(prev));
  1006. }
  1007. }
  1008. /**
  1009. * Add the specified delegate object to this PropertyHelper.
  1010. * Delegates are processed in LIFO order.
  1011. * @param delegate the delegate to add.
  1012. * @since Ant 1.8.0
  1013. */
  1014. public void add(Delegate delegate) {
  1015. synchronized (delegates) {
  1016. for (Class<? extends Delegate> key : getDelegateInterfaces(delegate)) {
  1017. List<Delegate> list = delegates.get(key);
  1018. if (list == null) {
  1019. list = new ArrayList<>();
  1020. } else {
  1021. //copy on write, top priority
  1022. list = new ArrayList<>(list);
  1023. list.remove(delegate);
  1024. }
  1025. list.add(0, delegate);
  1026. delegates.put(key, Collections.unmodifiableList(list));
  1027. }
  1028. }
  1029. }
  1030. /**
  1031. * Get the Collection of delegates of the specified type.
  1032. *
  1033. * @param <D> desired type.
  1034. * @param type
  1035. * delegate type.
  1036. * @return Collection.
  1037. * @since Ant 1.8.0
  1038. */
  1039. protected <D extends Delegate> List<D> getDelegates(Class<D> type) {
  1040. @SuppressWarnings("unchecked")
  1041. final List<D> result = (List<D>) delegates.get(type);
  1042. return result == null ? Collections.<D> emptyList() : result;
  1043. }
  1044. /**
  1045. * Get all Delegate interfaces (excluding Delegate itself) from the specified Delegate.
  1046. * @param d the Delegate to inspect.
  1047. * @return Set&lt;Class&gt;
  1048. * @since Ant 1.8.0
  1049. */
  1050. protected static Set<Class<? extends Delegate>> getDelegateInterfaces(Delegate d) {
  1051. final HashSet<Class<? extends Delegate>> result = new HashSet<>();
  1052. Class<?> c = d.getClass();
  1053. while (c != null) {
  1054. Class<?>[] ifs = c.getInterfaces();
  1055. for (int i = 0; i < ifs.length; i++) {
  1056. if (Delegate.class.isAssignableFrom(ifs[i])) {
  1057. @SuppressWarnings("unchecked")
  1058. final Class<? extends Delegate> delegateInterface = (Class<? extends Delegate>) ifs[i];
  1059. result.add(delegateInterface);
  1060. }
  1061. }
  1062. c = c.getSuperclass();
  1063. }
  1064. result.remove(Delegate.class);
  1065. return result;
  1066. }
  1067. /**
  1068. * If the given object can be interpreted as a true/false value,
  1069. * turn it into a matching Boolean - otherwise return null.
  1070. * @param value Object
  1071. * @return Boolean
  1072. * @since Ant 1.8.0
  1073. */
  1074. public static Boolean toBoolean(Object value) {
  1075. if (value instanceof Boolean) {
  1076. return (Boolean) value;
  1077. }
  1078. if (value instanceof String) {
  1079. String s = (String) value;
  1080. if (Project.toBoolean(s)) {
  1081. return Boolean.TRUE;
  1082. }
  1083. if ("off".equalsIgnoreCase(s)
  1084. || "false".equalsIgnoreCase(s)
  1085. || "no".equalsIgnoreCase(s)) {
  1086. return Boolean.FALSE;
  1087. }
  1088. }
  1089. return null;
  1090. }
  1091. /**
  1092. * Returns true if the object is null or an empty string.
  1093. *
  1094. * @param value Object
  1095. * @return boolean
  1096. * @since Ant 1.8.0
  1097. */
  1098. private static boolean nullOrEmpty(Object value) {
  1099. return value == null || "".equals(value);
  1100. }
  1101. /**
  1102. * Returns true if the value can be interpreted as a true value or
  1103. * cannot be interpreted as a false value and a property of the
  1104. * value's name exists.
  1105. * @param value Object
  1106. * @return boolean
  1107. * @since Ant 1.8.0
  1108. */
  1109. private boolean evalAsBooleanOrPropertyName(Object value) {
  1110. Boolean b = toBoolean(value);
  1111. if (b != null) {
  1112. return b.booleanValue();
  1113. }
  1114. return getProperty(String.valueOf(value)) != null;
  1115. }
  1116. /**
  1117. * Returns true if the value is null or an empty string, can be
  1118. * interpreted as a true value or cannot be interpreted as a false
  1119. * value and a property of the value's name exists.
  1120. * @param value Object
  1121. * @return boolean
  1122. * @since Ant 1.8.0
  1123. */
  1124. public boolean testIfCondition(Object value) {
  1125. return nullOrEmpty(value) || evalAsBooleanOrPropertyName(value);
  1126. }
  1127. /**
  1128. * Returns true if the value is null or an empty string, can be
  1129. * interpreted as a false value or cannot be interpreted as a true
  1130. * value and a property of the value's name doesn't exist.
  1131. * @param value Object
  1132. * @return boolean
  1133. * @since Ant 1.8.0
  1134. */
  1135. public boolean testUnlessCondition(Object value) {
  1136. return nullOrEmpty(value) || !evalAsBooleanOrPropertyName(value);
  1137. }
  1138. }