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 24 kB

"Dynamic properties" and a bit more. This is "slightly" different from embed - if dynamic properties will be accepted in 1.6, it is better to do it right. Embed uses few hacks to trick the ProjectHelper. PropertyHelper includes all the code related with property manipulation from Project (cut&paste). I added a very simple hook mechanism ( Filter/Valve like ) for the most common operations. The API is obviously far from final - someone who really understand "user" and "inherited" properties should review it and make few changes. In Project, all properties fields are private - so all can be removed. The methods related with properties will just delegate to PropertyHelper. From a user point of view - no visible change ( hopefully :-). Even grant will continue to work ( but won't be able to use the new features ). Benefits: - cleanup of Project. Less code and better organised. - Property handling will hopefully be cleaner too - we get to add APIs for namespace support, and maybe support non-string properties ( JSP-EL like - that needs to be disussed, but IMO it would be very helpfull ). While refs are Objects, the main distinction is imutability. Also: - apps embeding or extending ant can fully customize _all_ aspects of property processing, including ${} replacement and even the syntax. - it should be very easy to hook a different storage mechanism ( i.e. integrated with the embeding app, without requiring copy of properties ). - it should be possible to avoid copy when creating execution frames ( by using a chain that keeps changes and delegates getters ). - dynamic properties support ( my original itch :-) Please wait few days before firing, it seems all tests are passing and gump works - but I'm sure there are few problems :-) ( I'll commit the change in Project later today ) PR: Obtained from: Submitted by: Reviewed by: git-svn-id: https://svn.apache.org/repos/asf/ant/core/trunk@273709 13f79535-47bb-0310-9956-ffa450edef68
23 years ago
"Dynamic properties" and a bit more. This is "slightly" different from embed - if dynamic properties will be accepted in 1.6, it is better to do it right. Embed uses few hacks to trick the ProjectHelper. PropertyHelper includes all the code related with property manipulation from Project (cut&paste). I added a very simple hook mechanism ( Filter/Valve like ) for the most common operations. The API is obviously far from final - someone who really understand "user" and "inherited" properties should review it and make few changes. In Project, all properties fields are private - so all can be removed. The methods related with properties will just delegate to PropertyHelper. From a user point of view - no visible change ( hopefully :-). Even grant will continue to work ( but won't be able to use the new features ). Benefits: - cleanup of Project. Less code and better organised. - Property handling will hopefully be cleaner too - we get to add APIs for namespace support, and maybe support non-string properties ( JSP-EL like - that needs to be disussed, but IMO it would be very helpfull ). While refs are Objects, the main distinction is imutability. Also: - apps embeding or extending ant can fully customize _all_ aspects of property processing, including ${} replacement and even the syntax. - it should be very easy to hook a different storage mechanism ( i.e. integrated with the embeding app, without requiring copy of properties ). - it should be possible to avoid copy when creating execution frames ( by using a chain that keeps changes and delegates getters ). - dynamic properties support ( my original itch :-) Please wait few days before firing, it seems all tests are passing and gump works - but I'm sure there are few problems :-) ( I'll commit the change in Project later today ) PR: Obtained from: Submitted by: Reviewed by: git-svn-id: https://svn.apache.org/repos/asf/ant/core/trunk@273709 13f79535-47bb-0310-9956-ffa450edef68
23 years ago
"Dynamic properties" and a bit more. This is "slightly" different from embed - if dynamic properties will be accepted in 1.6, it is better to do it right. Embed uses few hacks to trick the ProjectHelper. PropertyHelper includes all the code related with property manipulation from Project (cut&paste). I added a very simple hook mechanism ( Filter/Valve like ) for the most common operations. The API is obviously far from final - someone who really understand "user" and "inherited" properties should review it and make few changes. In Project, all properties fields are private - so all can be removed. The methods related with properties will just delegate to PropertyHelper. From a user point of view - no visible change ( hopefully :-). Even grant will continue to work ( but won't be able to use the new features ). Benefits: - cleanup of Project. Less code and better organised. - Property handling will hopefully be cleaner too - we get to add APIs for namespace support, and maybe support non-string properties ( JSP-EL like - that needs to be disussed, but IMO it would be very helpfull ). While refs are Objects, the main distinction is imutability. Also: - apps embeding or extending ant can fully customize _all_ aspects of property processing, including ${} replacement and even the syntax. - it should be very easy to hook a different storage mechanism ( i.e. integrated with the embeding app, without requiring copy of properties ). - it should be possible to avoid copy when creating execution frames ( by using a chain that keeps changes and delegates getters ). - dynamic properties support ( my original itch :-) Please wait few days before firing, it seems all tests are passing and gump works - but I'm sure there are few problems :-) ( I'll commit the change in Project later today ) PR: Obtained from: Submitted by: Reviewed by: git-svn-id: https://svn.apache.org/repos/asf/ant/core/trunk@273709 13f79535-47bb-0310-9956-ffa450edef68
23 years ago
"Dynamic properties" and a bit more. This is "slightly" different from embed - if dynamic properties will be accepted in 1.6, it is better to do it right. Embed uses few hacks to trick the ProjectHelper. PropertyHelper includes all the code related with property manipulation from Project (cut&paste). I added a very simple hook mechanism ( Filter/Valve like ) for the most common operations. The API is obviously far from final - someone who really understand "user" and "inherited" properties should review it and make few changes. In Project, all properties fields are private - so all can be removed. The methods related with properties will just delegate to PropertyHelper. From a user point of view - no visible change ( hopefully :-). Even grant will continue to work ( but won't be able to use the new features ). Benefits: - cleanup of Project. Less code and better organised. - Property handling will hopefully be cleaner too - we get to add APIs for namespace support, and maybe support non-string properties ( JSP-EL like - that needs to be disussed, but IMO it would be very helpfull ). While refs are Objects, the main distinction is imutability. Also: - apps embeding or extending ant can fully customize _all_ aspects of property processing, including ${} replacement and even the syntax. - it should be very easy to hook a different storage mechanism ( i.e. integrated with the embeding app, without requiring copy of properties ). - it should be possible to avoid copy when creating execution frames ( by using a chain that keeps changes and delegates getters ). - dynamic properties support ( my original itch :-) Please wait few days before firing, it seems all tests are passing and gump works - but I'm sure there are few problems :-) ( I'll commit the change in Project later today ) PR: Obtained from: Submitted by: Reviewed by: git-svn-id: https://svn.apache.org/repos/asf/ant/core/trunk@273709 13f79535-47bb-0310-9956-ffa450edef68
23 years ago
"Dynamic properties" and a bit more. This is "slightly" different from embed - if dynamic properties will be accepted in 1.6, it is better to do it right. Embed uses few hacks to trick the ProjectHelper. PropertyHelper includes all the code related with property manipulation from Project (cut&paste). I added a very simple hook mechanism ( Filter/Valve like ) for the most common operations. The API is obviously far from final - someone who really understand "user" and "inherited" properties should review it and make few changes. In Project, all properties fields are private - so all can be removed. The methods related with properties will just delegate to PropertyHelper. From a user point of view - no visible change ( hopefully :-). Even grant will continue to work ( but won't be able to use the new features ). Benefits: - cleanup of Project. Less code and better organised. - Property handling will hopefully be cleaner too - we get to add APIs for namespace support, and maybe support non-string properties ( JSP-EL like - that needs to be disussed, but IMO it would be very helpfull ). While refs are Objects, the main distinction is imutability. Also: - apps embeding or extending ant can fully customize _all_ aspects of property processing, including ${} replacement and even the syntax. - it should be very easy to hook a different storage mechanism ( i.e. integrated with the embeding app, without requiring copy of properties ). - it should be possible to avoid copy when creating execution frames ( by using a chain that keeps changes and delegates getters ). - dynamic properties support ( my original itch :-) Please wait few days before firing, it seems all tests are passing and gump works - but I'm sure there are few problems :-) ( I'll commit the change in Project later today ) PR: Obtained from: Submitted by: Reviewed by: git-svn-id: https://svn.apache.org/repos/asf/ant/core/trunk@273709 13f79535-47bb-0310-9956-ffa450edef68
23 years ago
"Dynamic properties" and a bit more. This is "slightly" different from embed - if dynamic properties will be accepted in 1.6, it is better to do it right. Embed uses few hacks to trick the ProjectHelper. PropertyHelper includes all the code related with property manipulation from Project (cut&paste). I added a very simple hook mechanism ( Filter/Valve like ) for the most common operations. The API is obviously far from final - someone who really understand "user" and "inherited" properties should review it and make few changes. In Project, all properties fields are private - so all can be removed. The methods related with properties will just delegate to PropertyHelper. From a user point of view - no visible change ( hopefully :-). Even grant will continue to work ( but won't be able to use the new features ). Benefits: - cleanup of Project. Less code and better organised. - Property handling will hopefully be cleaner too - we get to add APIs for namespace support, and maybe support non-string properties ( JSP-EL like - that needs to be disussed, but IMO it would be very helpfull ). While refs are Objects, the main distinction is imutability. Also: - apps embeding or extending ant can fully customize _all_ aspects of property processing, including ${} replacement and even the syntax. - it should be very easy to hook a different storage mechanism ( i.e. integrated with the embeding app, without requiring copy of properties ). - it should be possible to avoid copy when creating execution frames ( by using a chain that keeps changes and delegates getters ). - dynamic properties support ( my original itch :-) Please wait few days before firing, it seems all tests are passing and gump works - but I'm sure there are few problems :-) ( I'll commit the change in Project later today ) PR: Obtained from: Submitted by: Reviewed by: git-svn-id: https://svn.apache.org/repos/asf/ant/core/trunk@273709 13f79535-47bb-0310-9956-ffa450edef68
23 years ago
"Dynamic properties" and a bit more. This is "slightly" different from embed - if dynamic properties will be accepted in 1.6, it is better to do it right. Embed uses few hacks to trick the ProjectHelper. PropertyHelper includes all the code related with property manipulation from Project (cut&paste). I added a very simple hook mechanism ( Filter/Valve like ) for the most common operations. The API is obviously far from final - someone who really understand "user" and "inherited" properties should review it and make few changes. In Project, all properties fields are private - so all can be removed. The methods related with properties will just delegate to PropertyHelper. From a user point of view - no visible change ( hopefully :-). Even grant will continue to work ( but won't be able to use the new features ). Benefits: - cleanup of Project. Less code and better organised. - Property handling will hopefully be cleaner too - we get to add APIs for namespace support, and maybe support non-string properties ( JSP-EL like - that needs to be disussed, but IMO it would be very helpfull ). While refs are Objects, the main distinction is imutability. Also: - apps embeding or extending ant can fully customize _all_ aspects of property processing, including ${} replacement and even the syntax. - it should be very easy to hook a different storage mechanism ( i.e. integrated with the embeding app, without requiring copy of properties ). - it should be possible to avoid copy when creating execution frames ( by using a chain that keeps changes and delegates getters ). - dynamic properties support ( my original itch :-) Please wait few days before firing, it seems all tests are passing and gump works - but I'm sure there are few problems :-) ( I'll commit the change in Project later today ) PR: Obtained from: Submitted by: Reviewed by: git-svn-id: https://svn.apache.org/repos/asf/ant/core/trunk@273709 13f79535-47bb-0310-9956-ffa450edef68
23 years ago
"Dynamic properties" and a bit more. This is "slightly" different from embed - if dynamic properties will be accepted in 1.6, it is better to do it right. Embed uses few hacks to trick the ProjectHelper. PropertyHelper includes all the code related with property manipulation from Project (cut&paste). I added a very simple hook mechanism ( Filter/Valve like ) for the most common operations. The API is obviously far from final - someone who really understand "user" and "inherited" properties should review it and make few changes. In Project, all properties fields are private - so all can be removed. The methods related with properties will just delegate to PropertyHelper. From a user point of view - no visible change ( hopefully :-). Even grant will continue to work ( but won't be able to use the new features ). Benefits: - cleanup of Project. Less code and better organised. - Property handling will hopefully be cleaner too - we get to add APIs for namespace support, and maybe support non-string properties ( JSP-EL like - that needs to be disussed, but IMO it would be very helpfull ). While refs are Objects, the main distinction is imutability. Also: - apps embeding or extending ant can fully customize _all_ aspects of property processing, including ${} replacement and even the syntax. - it should be very easy to hook a different storage mechanism ( i.e. integrated with the embeding app, without requiring copy of properties ). - it should be possible to avoid copy when creating execution frames ( by using a chain that keeps changes and delegates getters ). - dynamic properties support ( my original itch :-) Please wait few days before firing, it seems all tests are passing and gump works - but I'm sure there are few problems :-) ( I'll commit the change in Project later today ) PR: Obtained from: Submitted by: Reviewed by: git-svn-id: https://svn.apache.org/repos/asf/ant/core/trunk@273709 13f79535-47bb-0310-9956-ffa450edef68
23 years ago
"Dynamic properties" and a bit more. This is "slightly" different from embed - if dynamic properties will be accepted in 1.6, it is better to do it right. Embed uses few hacks to trick the ProjectHelper. PropertyHelper includes all the code related with property manipulation from Project (cut&paste). I added a very simple hook mechanism ( Filter/Valve like ) for the most common operations. The API is obviously far from final - someone who really understand "user" and "inherited" properties should review it and make few changes. In Project, all properties fields are private - so all can be removed. The methods related with properties will just delegate to PropertyHelper. From a user point of view - no visible change ( hopefully :-). Even grant will continue to work ( but won't be able to use the new features ). Benefits: - cleanup of Project. Less code and better organised. - Property handling will hopefully be cleaner too - we get to add APIs for namespace support, and maybe support non-string properties ( JSP-EL like - that needs to be disussed, but IMO it would be very helpfull ). While refs are Objects, the main distinction is imutability. Also: - apps embeding or extending ant can fully customize _all_ aspects of property processing, including ${} replacement and even the syntax. - it should be very easy to hook a different storage mechanism ( i.e. integrated with the embeding app, without requiring copy of properties ). - it should be possible to avoid copy when creating execution frames ( by using a chain that keeps changes and delegates getters ). - dynamic properties support ( my original itch :-) Please wait few days before firing, it seems all tests are passing and gump works - but I'm sure there are few problems :-) ( I'll commit the change in Project later today ) PR: Obtained from: Submitted by: Reviewed by: git-svn-id: https://svn.apache.org/repos/asf/ant/core/trunk@273709 13f79535-47bb-0310-9956-ffa450edef68
23 years ago
"Dynamic properties" and a bit more. This is "slightly" different from embed - if dynamic properties will be accepted in 1.6, it is better to do it right. Embed uses few hacks to trick the ProjectHelper. PropertyHelper includes all the code related with property manipulation from Project (cut&paste). I added a very simple hook mechanism ( Filter/Valve like ) for the most common operations. The API is obviously far from final - someone who really understand "user" and "inherited" properties should review it and make few changes. In Project, all properties fields are private - so all can be removed. The methods related with properties will just delegate to PropertyHelper. From a user point of view - no visible change ( hopefully :-). Even grant will continue to work ( but won't be able to use the new features ). Benefits: - cleanup of Project. Less code and better organised. - Property handling will hopefully be cleaner too - we get to add APIs for namespace support, and maybe support non-string properties ( JSP-EL like - that needs to be disussed, but IMO it would be very helpfull ). While refs are Objects, the main distinction is imutability. Also: - apps embeding or extending ant can fully customize _all_ aspects of property processing, including ${} replacement and even the syntax. - it should be very easy to hook a different storage mechanism ( i.e. integrated with the embeding app, without requiring copy of properties ). - it should be possible to avoid copy when creating execution frames ( by using a chain that keeps changes and delegates getters ). - dynamic properties support ( my original itch :-) Please wait few days before firing, it seems all tests are passing and gump works - but I'm sure there are few problems :-) ( I'll commit the change in Project later today ) PR: Obtained from: Submitted by: Reviewed by: git-svn-id: https://svn.apache.org/repos/asf/ant/core/trunk@273709 13f79535-47bb-0310-9956-ffa450edef68
23 years ago
"Dynamic properties" and a bit more. This is "slightly" different from embed - if dynamic properties will be accepted in 1.6, it is better to do it right. Embed uses few hacks to trick the ProjectHelper. PropertyHelper includes all the code related with property manipulation from Project (cut&paste). I added a very simple hook mechanism ( Filter/Valve like ) for the most common operations. The API is obviously far from final - someone who really understand "user" and "inherited" properties should review it and make few changes. In Project, all properties fields are private - so all can be removed. The methods related with properties will just delegate to PropertyHelper. From a user point of view - no visible change ( hopefully :-). Even grant will continue to work ( but won't be able to use the new features ). Benefits: - cleanup of Project. Less code and better organised. - Property handling will hopefully be cleaner too - we get to add APIs for namespace support, and maybe support non-string properties ( JSP-EL like - that needs to be disussed, but IMO it would be very helpfull ). While refs are Objects, the main distinction is imutability. Also: - apps embeding or extending ant can fully customize _all_ aspects of property processing, including ${} replacement and even the syntax. - it should be very easy to hook a different storage mechanism ( i.e. integrated with the embeding app, without requiring copy of properties ). - it should be possible to avoid copy when creating execution frames ( by using a chain that keeps changes and delegates getters ). - dynamic properties support ( my original itch :-) Please wait few days before firing, it seems all tests are passing and gump works - but I'm sure there are few problems :-) ( I'll commit the change in Project later today ) PR: Obtained from: Submitted by: Reviewed by: git-svn-id: https://svn.apache.org/repos/asf/ant/core/trunk@273709 13f79535-47bb-0310-9956-ffa450edef68
23 years ago
"Dynamic properties" and a bit more. This is "slightly" different from embed - if dynamic properties will be accepted in 1.6, it is better to do it right. Embed uses few hacks to trick the ProjectHelper. PropertyHelper includes all the code related with property manipulation from Project (cut&paste). I added a very simple hook mechanism ( Filter/Valve like ) for the most common operations. The API is obviously far from final - someone who really understand "user" and "inherited" properties should review it and make few changes. In Project, all properties fields are private - so all can be removed. The methods related with properties will just delegate to PropertyHelper. From a user point of view - no visible change ( hopefully :-). Even grant will continue to work ( but won't be able to use the new features ). Benefits: - cleanup of Project. Less code and better organised. - Property handling will hopefully be cleaner too - we get to add APIs for namespace support, and maybe support non-string properties ( JSP-EL like - that needs to be disussed, but IMO it would be very helpfull ). While refs are Objects, the main distinction is imutability. Also: - apps embeding or extending ant can fully customize _all_ aspects of property processing, including ${} replacement and even the syntax. - it should be very easy to hook a different storage mechanism ( i.e. integrated with the embeding app, without requiring copy of properties ). - it should be possible to avoid copy when creating execution frames ( by using a chain that keeps changes and delegates getters ). - dynamic properties support ( my original itch :-) Please wait few days before firing, it seems all tests are passing and gump works - but I'm sure there are few problems :-) ( I'll commit the change in Project later today ) PR: Obtained from: Submitted by: Reviewed by: git-svn-id: https://svn.apache.org/repos/asf/ant/core/trunk@273709 13f79535-47bb-0310-9956-ffa450edef68
23 years ago
"Dynamic properties" and a bit more. This is "slightly" different from embed - if dynamic properties will be accepted in 1.6, it is better to do it right. Embed uses few hacks to trick the ProjectHelper. PropertyHelper includes all the code related with property manipulation from Project (cut&paste). I added a very simple hook mechanism ( Filter/Valve like ) for the most common operations. The API is obviously far from final - someone who really understand "user" and "inherited" properties should review it and make few changes. In Project, all properties fields are private - so all can be removed. The methods related with properties will just delegate to PropertyHelper. From a user point of view - no visible change ( hopefully :-). Even grant will continue to work ( but won't be able to use the new features ). Benefits: - cleanup of Project. Less code and better organised. - Property handling will hopefully be cleaner too - we get to add APIs for namespace support, and maybe support non-string properties ( JSP-EL like - that needs to be disussed, but IMO it would be very helpfull ). While refs are Objects, the main distinction is imutability. Also: - apps embeding or extending ant can fully customize _all_ aspects of property processing, including ${} replacement and even the syntax. - it should be very easy to hook a different storage mechanism ( i.e. integrated with the embeding app, without requiring copy of properties ). - it should be possible to avoid copy when creating execution frames ( by using a chain that keeps changes and delegates getters ). - dynamic properties support ( my original itch :-) Please wait few days before firing, it seems all tests are passing and gump works - but I'm sure there are few problems :-) ( I'll commit the change in Project later today ) PR: Obtained from: Submitted by: Reviewed by: git-svn-id: https://svn.apache.org/repos/asf/ant/core/trunk@273709 13f79535-47bb-0310-9956-ffa450edef68
23 years ago
"Dynamic properties" and a bit more. This is "slightly" different from embed - if dynamic properties will be accepted in 1.6, it is better to do it right. Embed uses few hacks to trick the ProjectHelper. PropertyHelper includes all the code related with property manipulation from Project (cut&paste). I added a very simple hook mechanism ( Filter/Valve like ) for the most common operations. The API is obviously far from final - someone who really understand "user" and "inherited" properties should review it and make few changes. In Project, all properties fields are private - so all can be removed. The methods related with properties will just delegate to PropertyHelper. From a user point of view - no visible change ( hopefully :-). Even grant will continue to work ( but won't be able to use the new features ). Benefits: - cleanup of Project. Less code and better organised. - Property handling will hopefully be cleaner too - we get to add APIs for namespace support, and maybe support non-string properties ( JSP-EL like - that needs to be disussed, but IMO it would be very helpfull ). While refs are Objects, the main distinction is imutability. Also: - apps embeding or extending ant can fully customize _all_ aspects of property processing, including ${} replacement and even the syntax. - it should be very easy to hook a different storage mechanism ( i.e. integrated with the embeding app, without requiring copy of properties ). - it should be possible to avoid copy when creating execution frames ( by using a chain that keeps changes and delegates getters ). - dynamic properties support ( my original itch :-) Please wait few days before firing, it seems all tests are passing and gump works - but I'm sure there are few problems :-) ( I'll commit the change in Project later today ) PR: Obtained from: Submitted by: Reviewed by: git-svn-id: https://svn.apache.org/repos/asf/ant/core/trunk@273709 13f79535-47bb-0310-9956-ffa450edef68
23 years ago
"Dynamic properties" and a bit more. This is "slightly" different from embed - if dynamic properties will be accepted in 1.6, it is better to do it right. Embed uses few hacks to trick the ProjectHelper. PropertyHelper includes all the code related with property manipulation from Project (cut&paste). I added a very simple hook mechanism ( Filter/Valve like ) for the most common operations. The API is obviously far from final - someone who really understand "user" and "inherited" properties should review it and make few changes. In Project, all properties fields are private - so all can be removed. The methods related with properties will just delegate to PropertyHelper. From a user point of view - no visible change ( hopefully :-). Even grant will continue to work ( but won't be able to use the new features ). Benefits: - cleanup of Project. Less code and better organised. - Property handling will hopefully be cleaner too - we get to add APIs for namespace support, and maybe support non-string properties ( JSP-EL like - that needs to be disussed, but IMO it would be very helpfull ). While refs are Objects, the main distinction is imutability. Also: - apps embeding or extending ant can fully customize _all_ aspects of property processing, including ${} replacement and even the syntax. - it should be very easy to hook a different storage mechanism ( i.e. integrated with the embeding app, without requiring copy of properties ). - it should be possible to avoid copy when creating execution frames ( by using a chain that keeps changes and delegates getters ). - dynamic properties support ( my original itch :-) Please wait few days before firing, it seems all tests are passing and gump works - but I'm sure there are few problems :-) ( I'll commit the change in Project later today ) PR: Obtained from: Submitted by: Reviewed by: git-svn-id: https://svn.apache.org/repos/asf/ant/core/trunk@273709 13f79535-47bb-0310-9956-ffa450edef68
23 years ago
"Dynamic properties" and a bit more. This is "slightly" different from embed - if dynamic properties will be accepted in 1.6, it is better to do it right. Embed uses few hacks to trick the ProjectHelper. PropertyHelper includes all the code related with property manipulation from Project (cut&paste). I added a very simple hook mechanism ( Filter/Valve like ) for the most common operations. The API is obviously far from final - someone who really understand "user" and "inherited" properties should review it and make few changes. In Project, all properties fields are private - so all can be removed. The methods related with properties will just delegate to PropertyHelper. From a user point of view - no visible change ( hopefully :-). Even grant will continue to work ( but won't be able to use the new features ). Benefits: - cleanup of Project. Less code and better organised. - Property handling will hopefully be cleaner too - we get to add APIs for namespace support, and maybe support non-string properties ( JSP-EL like - that needs to be disussed, but IMO it would be very helpfull ). While refs are Objects, the main distinction is imutability. Also: - apps embeding or extending ant can fully customize _all_ aspects of property processing, including ${} replacement and even the syntax. - it should be very easy to hook a different storage mechanism ( i.e. integrated with the embeding app, without requiring copy of properties ). - it should be possible to avoid copy when creating execution frames ( by using a chain that keeps changes and delegates getters ). - dynamic properties support ( my original itch :-) Please wait few days before firing, it seems all tests are passing and gump works - but I'm sure there are few problems :-) ( I'll commit the change in Project later today ) PR: Obtained from: Submitted by: Reviewed by: git-svn-id: https://svn.apache.org/repos/asf/ant/core/trunk@273709 13f79535-47bb-0310-9956-ffa450edef68
23 years ago
"Dynamic properties" and a bit more. This is "slightly" different from embed - if dynamic properties will be accepted in 1.6, it is better to do it right. Embed uses few hacks to trick the ProjectHelper. PropertyHelper includes all the code related with property manipulation from Project (cut&paste). I added a very simple hook mechanism ( Filter/Valve like ) for the most common operations. The API is obviously far from final - someone who really understand "user" and "inherited" properties should review it and make few changes. In Project, all properties fields are private - so all can be removed. The methods related with properties will just delegate to PropertyHelper. From a user point of view - no visible change ( hopefully :-). Even grant will continue to work ( but won't be able to use the new features ). Benefits: - cleanup of Project. Less code and better organised. - Property handling will hopefully be cleaner too - we get to add APIs for namespace support, and maybe support non-string properties ( JSP-EL like - that needs to be disussed, but IMO it would be very helpfull ). While refs are Objects, the main distinction is imutability. Also: - apps embeding or extending ant can fully customize _all_ aspects of property processing, including ${} replacement and even the syntax. - it should be very easy to hook a different storage mechanism ( i.e. integrated with the embeding app, without requiring copy of properties ). - it should be possible to avoid copy when creating execution frames ( by using a chain that keeps changes and delegates getters ). - dynamic properties support ( my original itch :-) Please wait few days before firing, it seems all tests are passing and gump works - but I'm sure there are few problems :-) ( I'll commit the change in Project later today ) PR: Obtained from: Submitted by: Reviewed by: git-svn-id: https://svn.apache.org/repos/asf/ant/core/trunk@273709 13f79535-47bb-0310-9956-ffa450edef68
23 years ago
"Dynamic properties" and a bit more. This is "slightly" different from embed - if dynamic properties will be accepted in 1.6, it is better to do it right. Embed uses few hacks to trick the ProjectHelper. PropertyHelper includes all the code related with property manipulation from Project (cut&paste). I added a very simple hook mechanism ( Filter/Valve like ) for the most common operations. The API is obviously far from final - someone who really understand "user" and "inherited" properties should review it and make few changes. In Project, all properties fields are private - so all can be removed. The methods related with properties will just delegate to PropertyHelper. From a user point of view - no visible change ( hopefully :-). Even grant will continue to work ( but won't be able to use the new features ). Benefits: - cleanup of Project. Less code and better organised. - Property handling will hopefully be cleaner too - we get to add APIs for namespace support, and maybe support non-string properties ( JSP-EL like - that needs to be disussed, but IMO it would be very helpfull ). While refs are Objects, the main distinction is imutability. Also: - apps embeding or extending ant can fully customize _all_ aspects of property processing, including ${} replacement and even the syntax. - it should be very easy to hook a different storage mechanism ( i.e. integrated with the embeding app, without requiring copy of properties ). - it should be possible to avoid copy when creating execution frames ( by using a chain that keeps changes and delegates getters ). - dynamic properties support ( my original itch :-) Please wait few days before firing, it seems all tests are passing and gump works - but I'm sure there are few problems :-) ( I'll commit the change in Project later today ) PR: Obtained from: Submitted by: Reviewed by: git-svn-id: https://svn.apache.org/repos/asf/ant/core/trunk@273709 13f79535-47bb-0310-9956-ffa450edef68
23 years ago
"Dynamic properties" and a bit more. This is "slightly" different from embed - if dynamic properties will be accepted in 1.6, it is better to do it right. Embed uses few hacks to trick the ProjectHelper. PropertyHelper includes all the code related with property manipulation from Project (cut&paste). I added a very simple hook mechanism ( Filter/Valve like ) for the most common operations. The API is obviously far from final - someone who really understand "user" and "inherited" properties should review it and make few changes. In Project, all properties fields are private - so all can be removed. The methods related with properties will just delegate to PropertyHelper. From a user point of view - no visible change ( hopefully :-). Even grant will continue to work ( but won't be able to use the new features ). Benefits: - cleanup of Project. Less code and better organised. - Property handling will hopefully be cleaner too - we get to add APIs for namespace support, and maybe support non-string properties ( JSP-EL like - that needs to be disussed, but IMO it would be very helpfull ). While refs are Objects, the main distinction is imutability. Also: - apps embeding or extending ant can fully customize _all_ aspects of property processing, including ${} replacement and even the syntax. - it should be very easy to hook a different storage mechanism ( i.e. integrated with the embeding app, without requiring copy of properties ). - it should be possible to avoid copy when creating execution frames ( by using a chain that keeps changes and delegates getters ). - dynamic properties support ( my original itch :-) Please wait few days before firing, it seems all tests are passing and gump works - but I'm sure there are few problems :-) ( I'll commit the change in Project later today ) PR: Obtained from: Submitted by: Reviewed by: git-svn-id: https://svn.apache.org/repos/asf/ant/core/trunk@273709 13f79535-47bb-0310-9956-ffa450edef68
23 years ago
"Dynamic properties" and a bit more. This is "slightly" different from embed - if dynamic properties will be accepted in 1.6, it is better to do it right. Embed uses few hacks to trick the ProjectHelper. PropertyHelper includes all the code related with property manipulation from Project (cut&paste). I added a very simple hook mechanism ( Filter/Valve like ) for the most common operations. The API is obviously far from final - someone who really understand "user" and "inherited" properties should review it and make few changes. In Project, all properties fields are private - so all can be removed. The methods related with properties will just delegate to PropertyHelper. From a user point of view - no visible change ( hopefully :-). Even grant will continue to work ( but won't be able to use the new features ). Benefits: - cleanup of Project. Less code and better organised. - Property handling will hopefully be cleaner too - we get to add APIs for namespace support, and maybe support non-string properties ( JSP-EL like - that needs to be disussed, but IMO it would be very helpfull ). While refs are Objects, the main distinction is imutability. Also: - apps embeding or extending ant can fully customize _all_ aspects of property processing, including ${} replacement and even the syntax. - it should be very easy to hook a different storage mechanism ( i.e. integrated with the embeding app, without requiring copy of properties ). - it should be possible to avoid copy when creating execution frames ( by using a chain that keeps changes and delegates getters ). - dynamic properties support ( my original itch :-) Please wait few days before firing, it seems all tests are passing and gump works - but I'm sure there are few problems :-) ( I'll commit the change in Project later today ) PR: Obtained from: Submitted by: Reviewed by: git-svn-id: https://svn.apache.org/repos/asf/ant/core/trunk@273709 13f79535-47bb-0310-9956-ffa450edef68
23 years ago
"Dynamic properties" and a bit more. This is "slightly" different from embed - if dynamic properties will be accepted in 1.6, it is better to do it right. Embed uses few hacks to trick the ProjectHelper. PropertyHelper includes all the code related with property manipulation from Project (cut&paste). I added a very simple hook mechanism ( Filter/Valve like ) for the most common operations. The API is obviously far from final - someone who really understand "user" and "inherited" properties should review it and make few changes. In Project, all properties fields are private - so all can be removed. The methods related with properties will just delegate to PropertyHelper. From a user point of view - no visible change ( hopefully :-). Even grant will continue to work ( but won't be able to use the new features ). Benefits: - cleanup of Project. Less code and better organised. - Property handling will hopefully be cleaner too - we get to add APIs for namespace support, and maybe support non-string properties ( JSP-EL like - that needs to be disussed, but IMO it would be very helpfull ). While refs are Objects, the main distinction is imutability. Also: - apps embeding or extending ant can fully customize _all_ aspects of property processing, including ${} replacement and even the syntax. - it should be very easy to hook a different storage mechanism ( i.e. integrated with the embeding app, without requiring copy of properties ). - it should be possible to avoid copy when creating execution frames ( by using a chain that keeps changes and delegates getters ). - dynamic properties support ( my original itch :-) Please wait few days before firing, it seems all tests are passing and gump works - but I'm sure there are few problems :-) ( I'll commit the change in Project later today ) PR: Obtained from: Submitted by: Reviewed by: git-svn-id: https://svn.apache.org/repos/asf/ant/core/trunk@273709 13f79535-47bb-0310-9956-ffa450edef68
23 years ago
"Dynamic properties" and a bit more. This is "slightly" different from embed - if dynamic properties will be accepted in 1.6, it is better to do it right. Embed uses few hacks to trick the ProjectHelper. PropertyHelper includes all the code related with property manipulation from Project (cut&paste). I added a very simple hook mechanism ( Filter/Valve like ) for the most common operations. The API is obviously far from final - someone who really understand "user" and "inherited" properties should review it and make few changes. In Project, all properties fields are private - so all can be removed. The methods related with properties will just delegate to PropertyHelper. From a user point of view - no visible change ( hopefully :-). Even grant will continue to work ( but won't be able to use the new features ). Benefits: - cleanup of Project. Less code and better organised. - Property handling will hopefully be cleaner too - we get to add APIs for namespace support, and maybe support non-string properties ( JSP-EL like - that needs to be disussed, but IMO it would be very helpfull ). While refs are Objects, the main distinction is imutability. Also: - apps embeding or extending ant can fully customize _all_ aspects of property processing, including ${} replacement and even the syntax. - it should be very easy to hook a different storage mechanism ( i.e. integrated with the embeding app, without requiring copy of properties ). - it should be possible to avoid copy when creating execution frames ( by using a chain that keeps changes and delegates getters ). - dynamic properties support ( my original itch :-) Please wait few days before firing, it seems all tests are passing and gump works - but I'm sure there are few problems :-) ( I'll commit the change in Project later today ) PR: Obtained from: Submitted by: Reviewed by: git-svn-id: https://svn.apache.org/repos/asf/ant/core/trunk@273709 13f79535-47bb-0310-9956-ffa450edef68
23 years ago
"Dynamic properties" and a bit more. This is "slightly" different from embed - if dynamic properties will be accepted in 1.6, it is better to do it right. Embed uses few hacks to trick the ProjectHelper. PropertyHelper includes all the code related with property manipulation from Project (cut&paste). I added a very simple hook mechanism ( Filter/Valve like ) for the most common operations. The API is obviously far from final - someone who really understand "user" and "inherited" properties should review it and make few changes. In Project, all properties fields are private - so all can be removed. The methods related with properties will just delegate to PropertyHelper. From a user point of view - no visible change ( hopefully :-). Even grant will continue to work ( but won't be able to use the new features ). Benefits: - cleanup of Project. Less code and better organised. - Property handling will hopefully be cleaner too - we get to add APIs for namespace support, and maybe support non-string properties ( JSP-EL like - that needs to be disussed, but IMO it would be very helpfull ). While refs are Objects, the main distinction is imutability. Also: - apps embeding or extending ant can fully customize _all_ aspects of property processing, including ${} replacement and even the syntax. - it should be very easy to hook a different storage mechanism ( i.e. integrated with the embeding app, without requiring copy of properties ). - it should be possible to avoid copy when creating execution frames ( by using a chain that keeps changes and delegates getters ). - dynamic properties support ( my original itch :-) Please wait few days before firing, it seems all tests are passing and gump works - but I'm sure there are few problems :-) ( I'll commit the change in Project later today ) PR: Obtained from: Submitted by: Reviewed by: git-svn-id: https://svn.apache.org/repos/asf/ant/core/trunk@273709 13f79535-47bb-0310-9956-ffa450edef68
23 years ago
"Dynamic properties" and a bit more. This is "slightly" different from embed - if dynamic properties will be accepted in 1.6, it is better to do it right. Embed uses few hacks to trick the ProjectHelper. PropertyHelper includes all the code related with property manipulation from Project (cut&paste). I added a very simple hook mechanism ( Filter/Valve like ) for the most common operations. The API is obviously far from final - someone who really understand "user" and "inherited" properties should review it and make few changes. In Project, all properties fields are private - so all can be removed. The methods related with properties will just delegate to PropertyHelper. From a user point of view - no visible change ( hopefully :-). Even grant will continue to work ( but won't be able to use the new features ). Benefits: - cleanup of Project. Less code and better organised. - Property handling will hopefully be cleaner too - we get to add APIs for namespace support, and maybe support non-string properties ( JSP-EL like - that needs to be disussed, but IMO it would be very helpfull ). While refs are Objects, the main distinction is imutability. Also: - apps embeding or extending ant can fully customize _all_ aspects of property processing, including ${} replacement and even the syntax. - it should be very easy to hook a different storage mechanism ( i.e. integrated with the embeding app, without requiring copy of properties ). - it should be possible to avoid copy when creating execution frames ( by using a chain that keeps changes and delegates getters ). - dynamic properties support ( my original itch :-) Please wait few days before firing, it seems all tests are passing and gump works - but I'm sure there are few problems :-) ( I'll commit the change in Project later today ) PR: Obtained from: Submitted by: Reviewed by: git-svn-id: https://svn.apache.org/repos/asf/ant/core/trunk@273709 13f79535-47bb-0310-9956-ffa450edef68
23 years ago
"Dynamic properties" and a bit more. This is "slightly" different from embed - if dynamic properties will be accepted in 1.6, it is better to do it right. Embed uses few hacks to trick the ProjectHelper. PropertyHelper includes all the code related with property manipulation from Project (cut&paste). I added a very simple hook mechanism ( Filter/Valve like ) for the most common operations. The API is obviously far from final - someone who really understand "user" and "inherited" properties should review it and make few changes. In Project, all properties fields are private - so all can be removed. The methods related with properties will just delegate to PropertyHelper. From a user point of view - no visible change ( hopefully :-). Even grant will continue to work ( but won't be able to use the new features ). Benefits: - cleanup of Project. Less code and better organised. - Property handling will hopefully be cleaner too - we get to add APIs for namespace support, and maybe support non-string properties ( JSP-EL like - that needs to be disussed, but IMO it would be very helpfull ). While refs are Objects, the main distinction is imutability. Also: - apps embeding or extending ant can fully customize _all_ aspects of property processing, including ${} replacement and even the syntax. - it should be very easy to hook a different storage mechanism ( i.e. integrated with the embeding app, without requiring copy of properties ). - it should be possible to avoid copy when creating execution frames ( by using a chain that keeps changes and delegates getters ). - dynamic properties support ( my original itch :-) Please wait few days before firing, it seems all tests are passing and gump works - but I'm sure there are few problems :-) ( I'll commit the change in Project later today ) PR: Obtained from: Submitted by: Reviewed by: git-svn-id: https://svn.apache.org/repos/asf/ant/core/trunk@273709 13f79535-47bb-0310-9956-ffa450edef68
23 years ago
"Dynamic properties" and a bit more. This is "slightly" different from embed - if dynamic properties will be accepted in 1.6, it is better to do it right. Embed uses few hacks to trick the ProjectHelper. PropertyHelper includes all the code related with property manipulation from Project (cut&paste). I added a very simple hook mechanism ( Filter/Valve like ) for the most common operations. The API is obviously far from final - someone who really understand "user" and "inherited" properties should review it and make few changes. In Project, all properties fields are private - so all can be removed. The methods related with properties will just delegate to PropertyHelper. From a user point of view - no visible change ( hopefully :-). Even grant will continue to work ( but won't be able to use the new features ). Benefits: - cleanup of Project. Less code and better organised. - Property handling will hopefully be cleaner too - we get to add APIs for namespace support, and maybe support non-string properties ( JSP-EL like - that needs to be disussed, but IMO it would be very helpfull ). While refs are Objects, the main distinction is imutability. Also: - apps embeding or extending ant can fully customize _all_ aspects of property processing, including ${} replacement and even the syntax. - it should be very easy to hook a different storage mechanism ( i.e. integrated with the embeding app, without requiring copy of properties ). - it should be possible to avoid copy when creating execution frames ( by using a chain that keeps changes and delegates getters ). - dynamic properties support ( my original itch :-) Please wait few days before firing, it seems all tests are passing and gump works - but I'm sure there are few problems :-) ( I'll commit the change in Project later today ) PR: Obtained from: Submitted by: Reviewed by: git-svn-id: https://svn.apache.org/repos/asf/ant/core/trunk@273709 13f79535-47bb-0310-9956-ffa450edef68
23 years ago
"Dynamic properties" and a bit more. This is "slightly" different from embed - if dynamic properties will be accepted in 1.6, it is better to do it right. Embed uses few hacks to trick the ProjectHelper. PropertyHelper includes all the code related with property manipulation from Project (cut&paste). I added a very simple hook mechanism ( Filter/Valve like ) for the most common operations. The API is obviously far from final - someone who really understand "user" and "inherited" properties should review it and make few changes. In Project, all properties fields are private - so all can be removed. The methods related with properties will just delegate to PropertyHelper. From a user point of view - no visible change ( hopefully :-). Even grant will continue to work ( but won't be able to use the new features ). Benefits: - cleanup of Project. Less code and better organised. - Property handling will hopefully be cleaner too - we get to add APIs for namespace support, and maybe support non-string properties ( JSP-EL like - that needs to be disussed, but IMO it would be very helpfull ). While refs are Objects, the main distinction is imutability. Also: - apps embeding or extending ant can fully customize _all_ aspects of property processing, including ${} replacement and even the syntax. - it should be very easy to hook a different storage mechanism ( i.e. integrated with the embeding app, without requiring copy of properties ). - it should be possible to avoid copy when creating execution frames ( by using a chain that keeps changes and delegates getters ). - dynamic properties support ( my original itch :-) Please wait few days before firing, it seems all tests are passing and gump works - but I'm sure there are few problems :-) ( I'll commit the change in Project later today ) PR: Obtained from: Submitted by: Reviewed by: git-svn-id: https://svn.apache.org/repos/asf/ant/core/trunk@273709 13f79535-47bb-0310-9956-ffa450edef68
23 years ago
"Dynamic properties" and a bit more. This is "slightly" different from embed - if dynamic properties will be accepted in 1.6, it is better to do it right. Embed uses few hacks to trick the ProjectHelper. PropertyHelper includes all the code related with property manipulation from Project (cut&paste). I added a very simple hook mechanism ( Filter/Valve like ) for the most common operations. The API is obviously far from final - someone who really understand "user" and "inherited" properties should review it and make few changes. In Project, all properties fields are private - so all can be removed. The methods related with properties will just delegate to PropertyHelper. From a user point of view - no visible change ( hopefully :-). Even grant will continue to work ( but won't be able to use the new features ). Benefits: - cleanup of Project. Less code and better organised. - Property handling will hopefully be cleaner too - we get to add APIs for namespace support, and maybe support non-string properties ( JSP-EL like - that needs to be disussed, but IMO it would be very helpfull ). While refs are Objects, the main distinction is imutability. Also: - apps embeding or extending ant can fully customize _all_ aspects of property processing, including ${} replacement and even the syntax. - it should be very easy to hook a different storage mechanism ( i.e. integrated with the embeding app, without requiring copy of properties ). - it should be possible to avoid copy when creating execution frames ( by using a chain that keeps changes and delegates getters ). - dynamic properties support ( my original itch :-) Please wait few days before firing, it seems all tests are passing and gump works - but I'm sure there are few problems :-) ( I'll commit the change in Project later today ) PR: Obtained from: Submitted by: Reviewed by: git-svn-id: https://svn.apache.org/repos/asf/ant/core/trunk@273709 13f79535-47bb-0310-9956-ffa450edef68
23 years ago
"Dynamic properties" and a bit more. This is "slightly" different from embed - if dynamic properties will be accepted in 1.6, it is better to do it right. Embed uses few hacks to trick the ProjectHelper. PropertyHelper includes all the code related with property manipulation from Project (cut&paste). I added a very simple hook mechanism ( Filter/Valve like ) for the most common operations. The API is obviously far from final - someone who really understand "user" and "inherited" properties should review it and make few changes. In Project, all properties fields are private - so all can be removed. The methods related with properties will just delegate to PropertyHelper. From a user point of view - no visible change ( hopefully :-). Even grant will continue to work ( but won't be able to use the new features ). Benefits: - cleanup of Project. Less code and better organised. - Property handling will hopefully be cleaner too - we get to add APIs for namespace support, and maybe support non-string properties ( JSP-EL like - that needs to be disussed, but IMO it would be very helpfull ). While refs are Objects, the main distinction is imutability. Also: - apps embeding or extending ant can fully customize _all_ aspects of property processing, including ${} replacement and even the syntax. - it should be very easy to hook a different storage mechanism ( i.e. integrated with the embeding app, without requiring copy of properties ). - it should be possible to avoid copy when creating execution frames ( by using a chain that keeps changes and delegates getters ). - dynamic properties support ( my original itch :-) Please wait few days before firing, it seems all tests are passing and gump works - but I'm sure there are few problems :-) ( I'll commit the change in Project later today ) PR: Obtained from: Submitted by: Reviewed by: git-svn-id: https://svn.apache.org/repos/asf/ant/core/trunk@273709 13f79535-47bb-0310-9956-ffa450edef68
23 years ago
"Dynamic properties" and a bit more. This is "slightly" different from embed - if dynamic properties will be accepted in 1.6, it is better to do it right. Embed uses few hacks to trick the ProjectHelper. PropertyHelper includes all the code related with property manipulation from Project (cut&paste). I added a very simple hook mechanism ( Filter/Valve like ) for the most common operations. The API is obviously far from final - someone who really understand "user" and "inherited" properties should review it and make few changes. In Project, all properties fields are private - so all can be removed. The methods related with properties will just delegate to PropertyHelper. From a user point of view - no visible change ( hopefully :-). Even grant will continue to work ( but won't be able to use the new features ). Benefits: - cleanup of Project. Less code and better organised. - Property handling will hopefully be cleaner too - we get to add APIs for namespace support, and maybe support non-string properties ( JSP-EL like - that needs to be disussed, but IMO it would be very helpfull ). While refs are Objects, the main distinction is imutability. Also: - apps embeding or extending ant can fully customize _all_ aspects of property processing, including ${} replacement and even the syntax. - it should be very easy to hook a different storage mechanism ( i.e. integrated with the embeding app, without requiring copy of properties ). - it should be possible to avoid copy when creating execution frames ( by using a chain that keeps changes and delegates getters ). - dynamic properties support ( my original itch :-) Please wait few days before firing, it seems all tests are passing and gump works - but I'm sure there are few problems :-) ( I'll commit the change in Project later today ) PR: Obtained from: Submitted by: Reviewed by: git-svn-id: https://svn.apache.org/repos/asf/ant/core/trunk@273709 13f79535-47bb-0310-9956-ffa450edef68
23 years ago
"Dynamic properties" and a bit more. This is "slightly" different from embed - if dynamic properties will be accepted in 1.6, it is better to do it right. Embed uses few hacks to trick the ProjectHelper. PropertyHelper includes all the code related with property manipulation from Project (cut&paste). I added a very simple hook mechanism ( Filter/Valve like ) for the most common operations. The API is obviously far from final - someone who really understand "user" and "inherited" properties should review it and make few changes. In Project, all properties fields are private - so all can be removed. The methods related with properties will just delegate to PropertyHelper. From a user point of view - no visible change ( hopefully :-). Even grant will continue to work ( but won't be able to use the new features ). Benefits: - cleanup of Project. Less code and better organised. - Property handling will hopefully be cleaner too - we get to add APIs for namespace support, and maybe support non-string properties ( JSP-EL like - that needs to be disussed, but IMO it would be very helpfull ). While refs are Objects, the main distinction is imutability. Also: - apps embeding or extending ant can fully customize _all_ aspects of property processing, including ${} replacement and even the syntax. - it should be very easy to hook a different storage mechanism ( i.e. integrated with the embeding app, without requiring copy of properties ). - it should be possible to avoid copy when creating execution frames ( by using a chain that keeps changes and delegates getters ). - dynamic properties support ( my original itch :-) Please wait few days before firing, it seems all tests are passing and gump works - but I'm sure there are few problems :-) ( I'll commit the change in Project later today ) PR: Obtained from: Submitted by: Reviewed by: git-svn-id: https://svn.apache.org/repos/asf/ant/core/trunk@273709 13f79535-47bb-0310-9956-ffa450edef68
23 years ago
"Dynamic properties" and a bit more. This is "slightly" different from embed - if dynamic properties will be accepted in 1.6, it is better to do it right. Embed uses few hacks to trick the ProjectHelper. PropertyHelper includes all the code related with property manipulation from Project (cut&paste). I added a very simple hook mechanism ( Filter/Valve like ) for the most common operations. The API is obviously far from final - someone who really understand "user" and "inherited" properties should review it and make few changes. In Project, all properties fields are private - so all can be removed. The methods related with properties will just delegate to PropertyHelper. From a user point of view - no visible change ( hopefully :-). Even grant will continue to work ( but won't be able to use the new features ). Benefits: - cleanup of Project. Less code and better organised. - Property handling will hopefully be cleaner too - we get to add APIs for namespace support, and maybe support non-string properties ( JSP-EL like - that needs to be disussed, but IMO it would be very helpfull ). While refs are Objects, the main distinction is imutability. Also: - apps embeding or extending ant can fully customize _all_ aspects of property processing, including ${} replacement and even the syntax. - it should be very easy to hook a different storage mechanism ( i.e. integrated with the embeding app, without requiring copy of properties ). - it should be possible to avoid copy when creating execution frames ( by using a chain that keeps changes and delegates getters ). - dynamic properties support ( my original itch :-) Please wait few days before firing, it seems all tests are passing and gump works - but I'm sure there are few problems :-) ( I'll commit the change in Project later today ) PR: Obtained from: Submitted by: Reviewed by: git-svn-id: https://svn.apache.org/repos/asf/ant/core/trunk@273709 13f79535-47bb-0310-9956-ffa450edef68
23 years ago
"Dynamic properties" and a bit more. This is "slightly" different from embed - if dynamic properties will be accepted in 1.6, it is better to do it right. Embed uses few hacks to trick the ProjectHelper. PropertyHelper includes all the code related with property manipulation from Project (cut&paste). I added a very simple hook mechanism ( Filter/Valve like ) for the most common operations. The API is obviously far from final - someone who really understand "user" and "inherited" properties should review it and make few changes. In Project, all properties fields are private - so all can be removed. The methods related with properties will just delegate to PropertyHelper. From a user point of view - no visible change ( hopefully :-). Even grant will continue to work ( but won't be able to use the new features ). Benefits: - cleanup of Project. Less code and better organised. - Property handling will hopefully be cleaner too - we get to add APIs for namespace support, and maybe support non-string properties ( JSP-EL like - that needs to be disussed, but IMO it would be very helpfull ). While refs are Objects, the main distinction is imutability. Also: - apps embeding or extending ant can fully customize _all_ aspects of property processing, including ${} replacement and even the syntax. - it should be very easy to hook a different storage mechanism ( i.e. integrated with the embeding app, without requiring copy of properties ). - it should be possible to avoid copy when creating execution frames ( by using a chain that keeps changes and delegates getters ). - dynamic properties support ( my original itch :-) Please wait few days before firing, it seems all tests are passing and gump works - but I'm sure there are few problems :-) ( I'll commit the change in Project later today ) PR: Obtained from: Submitted by: Reviewed by: git-svn-id: https://svn.apache.org/repos/asf/ant/core/trunk@273709 13f79535-47bb-0310-9956-ffa450edef68
23 years ago
"Dynamic properties" and a bit more. This is "slightly" different from embed - if dynamic properties will be accepted in 1.6, it is better to do it right. Embed uses few hacks to trick the ProjectHelper. PropertyHelper includes all the code related with property manipulation from Project (cut&paste). I added a very simple hook mechanism ( Filter/Valve like ) for the most common operations. The API is obviously far from final - someone who really understand "user" and "inherited" properties should review it and make few changes. In Project, all properties fields are private - so all can be removed. The methods related with properties will just delegate to PropertyHelper. From a user point of view - no visible change ( hopefully :-). Even grant will continue to work ( but won't be able to use the new features ). Benefits: - cleanup of Project. Less code and better organised. - Property handling will hopefully be cleaner too - we get to add APIs for namespace support, and maybe support non-string properties ( JSP-EL like - that needs to be disussed, but IMO it would be very helpfull ). While refs are Objects, the main distinction is imutability. Also: - apps embeding or extending ant can fully customize _all_ aspects of property processing, including ${} replacement and even the syntax. - it should be very easy to hook a different storage mechanism ( i.e. integrated with the embeding app, without requiring copy of properties ). - it should be possible to avoid copy when creating execution frames ( by using a chain that keeps changes and delegates getters ). - dynamic properties support ( my original itch :-) Please wait few days before firing, it seems all tests are passing and gump works - but I'm sure there are few problems :-) ( I'll commit the change in Project later today ) PR: Obtained from: Submitted by: Reviewed by: git-svn-id: https://svn.apache.org/repos/asf/ant/core/trunk@273709 13f79535-47bb-0310-9956-ffa450edef68
23 years ago
"Dynamic properties" and a bit more. This is "slightly" different from embed - if dynamic properties will be accepted in 1.6, it is better to do it right. Embed uses few hacks to trick the ProjectHelper. PropertyHelper includes all the code related with property manipulation from Project (cut&paste). I added a very simple hook mechanism ( Filter/Valve like ) for the most common operations. The API is obviously far from final - someone who really understand "user" and "inherited" properties should review it and make few changes. In Project, all properties fields are private - so all can be removed. The methods related with properties will just delegate to PropertyHelper. From a user point of view - no visible change ( hopefully :-). Even grant will continue to work ( but won't be able to use the new features ). Benefits: - cleanup of Project. Less code and better organised. - Property handling will hopefully be cleaner too - we get to add APIs for namespace support, and maybe support non-string properties ( JSP-EL like - that needs to be disussed, but IMO it would be very helpfull ). While refs are Objects, the main distinction is imutability. Also: - apps embeding or extending ant can fully customize _all_ aspects of property processing, including ${} replacement and even the syntax. - it should be very easy to hook a different storage mechanism ( i.e. integrated with the embeding app, without requiring copy of properties ). - it should be possible to avoid copy when creating execution frames ( by using a chain that keeps changes and delegates getters ). - dynamic properties support ( my original itch :-) Please wait few days before firing, it seems all tests are passing and gump works - but I'm sure there are few problems :-) ( I'll commit the change in Project later today ) PR: Obtained from: Submitted by: Reviewed by: git-svn-id: https://svn.apache.org/repos/asf/ant/core/trunk@273709 13f79535-47bb-0310-9956-ffa450edef68
23 years ago
"Dynamic properties" and a bit more. This is "slightly" different from embed - if dynamic properties will be accepted in 1.6, it is better to do it right. Embed uses few hacks to trick the ProjectHelper. PropertyHelper includes all the code related with property manipulation from Project (cut&paste). I added a very simple hook mechanism ( Filter/Valve like ) for the most common operations. The API is obviously far from final - someone who really understand "user" and "inherited" properties should review it and make few changes. In Project, all properties fields are private - so all can be removed. The methods related with properties will just delegate to PropertyHelper. From a user point of view - no visible change ( hopefully :-). Even grant will continue to work ( but won't be able to use the new features ). Benefits: - cleanup of Project. Less code and better organised. - Property handling will hopefully be cleaner too - we get to add APIs for namespace support, and maybe support non-string properties ( JSP-EL like - that needs to be disussed, but IMO it would be very helpfull ). While refs are Objects, the main distinction is imutability. Also: - apps embeding or extending ant can fully customize _all_ aspects of property processing, including ${} replacement and even the syntax. - it should be very easy to hook a different storage mechanism ( i.e. integrated with the embeding app, without requiring copy of properties ). - it should be possible to avoid copy when creating execution frames ( by using a chain that keeps changes and delegates getters ). - dynamic properties support ( my original itch :-) Please wait few days before firing, it seems all tests are passing and gump works - but I'm sure there are few problems :-) ( I'll commit the change in Project later today ) PR: Obtained from: Submitted by: Reviewed by: git-svn-id: https://svn.apache.org/repos/asf/ant/core/trunk@273709 13f79535-47bb-0310-9956-ffa450edef68
23 years ago
"Dynamic properties" and a bit more. This is "slightly" different from embed - if dynamic properties will be accepted in 1.6, it is better to do it right. Embed uses few hacks to trick the ProjectHelper. PropertyHelper includes all the code related with property manipulation from Project (cut&paste). I added a very simple hook mechanism ( Filter/Valve like ) for the most common operations. The API is obviously far from final - someone who really understand "user" and "inherited" properties should review it and make few changes. In Project, all properties fields are private - so all can be removed. The methods related with properties will just delegate to PropertyHelper. From a user point of view - no visible change ( hopefully :-). Even grant will continue to work ( but won't be able to use the new features ). Benefits: - cleanup of Project. Less code and better organised. - Property handling will hopefully be cleaner too - we get to add APIs for namespace support, and maybe support non-string properties ( JSP-EL like - that needs to be disussed, but IMO it would be very helpfull ). While refs are Objects, the main distinction is imutability. Also: - apps embeding or extending ant can fully customize _all_ aspects of property processing, including ${} replacement and even the syntax. - it should be very easy to hook a different storage mechanism ( i.e. integrated with the embeding app, without requiring copy of properties ). - it should be possible to avoid copy when creating execution frames ( by using a chain that keeps changes and delegates getters ). - dynamic properties support ( my original itch :-) Please wait few days before firing, it seems all tests are passing and gump works - but I'm sure there are few problems :-) ( I'll commit the change in Project later today ) PR: Obtained from: Submitted by: Reviewed by: git-svn-id: https://svn.apache.org/repos/asf/ant/core/trunk@273709 13f79535-47bb-0310-9956-ffa450edef68
23 years ago
"Dynamic properties" and a bit more. This is "slightly" different from embed - if dynamic properties will be accepted in 1.6, it is better to do it right. Embed uses few hacks to trick the ProjectHelper. PropertyHelper includes all the code related with property manipulation from Project (cut&paste). I added a very simple hook mechanism ( Filter/Valve like ) for the most common operations. The API is obviously far from final - someone who really understand "user" and "inherited" properties should review it and make few changes. In Project, all properties fields are private - so all can be removed. The methods related with properties will just delegate to PropertyHelper. From a user point of view - no visible change ( hopefully :-). Even grant will continue to work ( but won't be able to use the new features ). Benefits: - cleanup of Project. Less code and better organised. - Property handling will hopefully be cleaner too - we get to add APIs for namespace support, and maybe support non-string properties ( JSP-EL like - that needs to be disussed, but IMO it would be very helpfull ). While refs are Objects, the main distinction is imutability. Also: - apps embeding or extending ant can fully customize _all_ aspects of property processing, including ${} replacement and even the syntax. - it should be very easy to hook a different storage mechanism ( i.e. integrated with the embeding app, without requiring copy of properties ). - it should be possible to avoid copy when creating execution frames ( by using a chain that keeps changes and delegates getters ). - dynamic properties support ( my original itch :-) Please wait few days before firing, it seems all tests are passing and gump works - but I'm sure there are few problems :-) ( I'll commit the change in Project later today ) PR: Obtained from: Submitted by: Reviewed by: git-svn-id: https://svn.apache.org/repos/asf/ant/core/trunk@273709 13f79535-47bb-0310-9956-ffa450edef68
23 years ago
"Dynamic properties" and a bit more. This is "slightly" different from embed - if dynamic properties will be accepted in 1.6, it is better to do it right. Embed uses few hacks to trick the ProjectHelper. PropertyHelper includes all the code related with property manipulation from Project (cut&paste). I added a very simple hook mechanism ( Filter/Valve like ) for the most common operations. The API is obviously far from final - someone who really understand "user" and "inherited" properties should review it and make few changes. In Project, all properties fields are private - so all can be removed. The methods related with properties will just delegate to PropertyHelper. From a user point of view - no visible change ( hopefully :-). Even grant will continue to work ( but won't be able to use the new features ). Benefits: - cleanup of Project. Less code and better organised. - Property handling will hopefully be cleaner too - we get to add APIs for namespace support, and maybe support non-string properties ( JSP-EL like - that needs to be disussed, but IMO it would be very helpfull ). While refs are Objects, the main distinction is imutability. Also: - apps embeding or extending ant can fully customize _all_ aspects of property processing, including ${} replacement and even the syntax. - it should be very easy to hook a different storage mechanism ( i.e. integrated with the embeding app, without requiring copy of properties ). - it should be possible to avoid copy when creating execution frames ( by using a chain that keeps changes and delegates getters ). - dynamic properties support ( my original itch :-) Please wait few days before firing, it seems all tests are passing and gump works - but I'm sure there are few problems :-) ( I'll commit the change in Project later today ) PR: Obtained from: Submitted by: Reviewed by: git-svn-id: https://svn.apache.org/repos/asf/ant/core/trunk@273709 13f79535-47bb-0310-9956-ffa450edef68
23 years ago
"Dynamic properties" and a bit more. This is "slightly" different from embed - if dynamic properties will be accepted in 1.6, it is better to do it right. Embed uses few hacks to trick the ProjectHelper. PropertyHelper includes all the code related with property manipulation from Project (cut&paste). I added a very simple hook mechanism ( Filter/Valve like ) for the most common operations. The API is obviously far from final - someone who really understand "user" and "inherited" properties should review it and make few changes. In Project, all properties fields are private - so all can be removed. The methods related with properties will just delegate to PropertyHelper. From a user point of view - no visible change ( hopefully :-). Even grant will continue to work ( but won't be able to use the new features ). Benefits: - cleanup of Project. Less code and better organised. - Property handling will hopefully be cleaner too - we get to add APIs for namespace support, and maybe support non-string properties ( JSP-EL like - that needs to be disussed, but IMO it would be very helpfull ). While refs are Objects, the main distinction is imutability. Also: - apps embeding or extending ant can fully customize _all_ aspects of property processing, including ${} replacement and even the syntax. - it should be very easy to hook a different storage mechanism ( i.e. integrated with the embeding app, without requiring copy of properties ). - it should be possible to avoid copy when creating execution frames ( by using a chain that keeps changes and delegates getters ). - dynamic properties support ( my original itch :-) Please wait few days before firing, it seems all tests are passing and gump works - but I'm sure there are few problems :-) ( I'll commit the change in Project later today ) PR: Obtained from: Submitted by: Reviewed by: git-svn-id: https://svn.apache.org/repos/asf/ant/core/trunk@273709 13f79535-47bb-0310-9956-ffa450edef68
23 years ago
"Dynamic properties" and a bit more. This is "slightly" different from embed - if dynamic properties will be accepted in 1.6, it is better to do it right. Embed uses few hacks to trick the ProjectHelper. PropertyHelper includes all the code related with property manipulation from Project (cut&paste). I added a very simple hook mechanism ( Filter/Valve like ) for the most common operations. The API is obviously far from final - someone who really understand "user" and "inherited" properties should review it and make few changes. In Project, all properties fields are private - so all can be removed. The methods related with properties will just delegate to PropertyHelper. From a user point of view - no visible change ( hopefully :-). Even grant will continue to work ( but won't be able to use the new features ). Benefits: - cleanup of Project. Less code and better organised. - Property handling will hopefully be cleaner too - we get to add APIs for namespace support, and maybe support non-string properties ( JSP-EL like - that needs to be disussed, but IMO it would be very helpfull ). While refs are Objects, the main distinction is imutability. Also: - apps embeding or extending ant can fully customize _all_ aspects of property processing, including ${} replacement and even the syntax. - it should be very easy to hook a different storage mechanism ( i.e. integrated with the embeding app, without requiring copy of properties ). - it should be possible to avoid copy when creating execution frames ( by using a chain that keeps changes and delegates getters ). - dynamic properties support ( my original itch :-) Please wait few days before firing, it seems all tests are passing and gump works - but I'm sure there are few problems :-) ( I'll commit the change in Project later today ) PR: Obtained from: Submitted by: Reviewed by: git-svn-id: https://svn.apache.org/repos/asf/ant/core/trunk@273709 13f79535-47bb-0310-9956-ffa450edef68
23 years ago
"Dynamic properties" and a bit more. This is "slightly" different from embed - if dynamic properties will be accepted in 1.6, it is better to do it right. Embed uses few hacks to trick the ProjectHelper. PropertyHelper includes all the code related with property manipulation from Project (cut&paste). I added a very simple hook mechanism ( Filter/Valve like ) for the most common operations. The API is obviously far from final - someone who really understand "user" and "inherited" properties should review it and make few changes. In Project, all properties fields are private - so all can be removed. The methods related with properties will just delegate to PropertyHelper. From a user point of view - no visible change ( hopefully :-). Even grant will continue to work ( but won't be able to use the new features ). Benefits: - cleanup of Project. Less code and better organised. - Property handling will hopefully be cleaner too - we get to add APIs for namespace support, and maybe support non-string properties ( JSP-EL like - that needs to be disussed, but IMO it would be very helpfull ). While refs are Objects, the main distinction is imutability. Also: - apps embeding or extending ant can fully customize _all_ aspects of property processing, including ${} replacement and even the syntax. - it should be very easy to hook a different storage mechanism ( i.e. integrated with the embeding app, without requiring copy of properties ). - it should be possible to avoid copy when creating execution frames ( by using a chain that keeps changes and delegates getters ). - dynamic properties support ( my original itch :-) Please wait few days before firing, it seems all tests are passing and gump works - but I'm sure there are few problems :-) ( I'll commit the change in Project later today ) PR: Obtained from: Submitted by: Reviewed by: git-svn-id: https://svn.apache.org/repos/asf/ant/core/trunk@273709 13f79535-47bb-0310-9956-ffa450edef68
23 years ago
"Dynamic properties" and a bit more. This is "slightly" different from embed - if dynamic properties will be accepted in 1.6, it is better to do it right. Embed uses few hacks to trick the ProjectHelper. PropertyHelper includes all the code related with property manipulation from Project (cut&paste). I added a very simple hook mechanism ( Filter/Valve like ) for the most common operations. The API is obviously far from final - someone who really understand "user" and "inherited" properties should review it and make few changes. In Project, all properties fields are private - so all can be removed. The methods related with properties will just delegate to PropertyHelper. From a user point of view - no visible change ( hopefully :-). Even grant will continue to work ( but won't be able to use the new features ). Benefits: - cleanup of Project. Less code and better organised. - Property handling will hopefully be cleaner too - we get to add APIs for namespace support, and maybe support non-string properties ( JSP-EL like - that needs to be disussed, but IMO it would be very helpfull ). While refs are Objects, the main distinction is imutability. Also: - apps embeding or extending ant can fully customize _all_ aspects of property processing, including ${} replacement and even the syntax. - it should be very easy to hook a different storage mechanism ( i.e. integrated with the embeding app, without requiring copy of properties ). - it should be possible to avoid copy when creating execution frames ( by using a chain that keeps changes and delegates getters ). - dynamic properties support ( my original itch :-) Please wait few days before firing, it seems all tests are passing and gump works - but I'm sure there are few problems :-) ( I'll commit the change in Project later today ) PR: Obtained from: Submitted by: Reviewed by: git-svn-id: https://svn.apache.org/repos/asf/ant/core/trunk@273709 13f79535-47bb-0310-9956-ffa450edef68
23 years ago
"Dynamic properties" and a bit more. This is "slightly" different from embed - if dynamic properties will be accepted in 1.6, it is better to do it right. Embed uses few hacks to trick the ProjectHelper. PropertyHelper includes all the code related with property manipulation from Project (cut&paste). I added a very simple hook mechanism ( Filter/Valve like ) for the most common operations. The API is obviously far from final - someone who really understand "user" and "inherited" properties should review it and make few changes. In Project, all properties fields are private - so all can be removed. The methods related with properties will just delegate to PropertyHelper. From a user point of view - no visible change ( hopefully :-). Even grant will continue to work ( but won't be able to use the new features ). Benefits: - cleanup of Project. Less code and better organised. - Property handling will hopefully be cleaner too - we get to add APIs for namespace support, and maybe support non-string properties ( JSP-EL like - that needs to be disussed, but IMO it would be very helpfull ). While refs are Objects, the main distinction is imutability. Also: - apps embeding or extending ant can fully customize _all_ aspects of property processing, including ${} replacement and even the syntax. - it should be very easy to hook a different storage mechanism ( i.e. integrated with the embeding app, without requiring copy of properties ). - it should be possible to avoid copy when creating execution frames ( by using a chain that keeps changes and delegates getters ). - dynamic properties support ( my original itch :-) Please wait few days before firing, it seems all tests are passing and gump works - but I'm sure there are few problems :-) ( I'll commit the change in Project later today ) PR: Obtained from: Submitted by: Reviewed by: git-svn-id: https://svn.apache.org/repos/asf/ant/core/trunk@273709 13f79535-47bb-0310-9956-ffa450edef68
23 years ago
"Dynamic properties" and a bit more. This is "slightly" different from embed - if dynamic properties will be accepted in 1.6, it is better to do it right. Embed uses few hacks to trick the ProjectHelper. PropertyHelper includes all the code related with property manipulation from Project (cut&paste). I added a very simple hook mechanism ( Filter/Valve like ) for the most common operations. The API is obviously far from final - someone who really understand "user" and "inherited" properties should review it and make few changes. In Project, all properties fields are private - so all can be removed. The methods related with properties will just delegate to PropertyHelper. From a user point of view - no visible change ( hopefully :-). Even grant will continue to work ( but won't be able to use the new features ). Benefits: - cleanup of Project. Less code and better organised. - Property handling will hopefully be cleaner too - we get to add APIs for namespace support, and maybe support non-string properties ( JSP-EL like - that needs to be disussed, but IMO it would be very helpfull ). While refs are Objects, the main distinction is imutability. Also: - apps embeding or extending ant can fully customize _all_ aspects of property processing, including ${} replacement and even the syntax. - it should be very easy to hook a different storage mechanism ( i.e. integrated with the embeding app, without requiring copy of properties ). - it should be possible to avoid copy when creating execution frames ( by using a chain that keeps changes and delegates getters ). - dynamic properties support ( my original itch :-) Please wait few days before firing, it seems all tests are passing and gump works - but I'm sure there are few problems :-) ( I'll commit the change in Project later today ) PR: Obtained from: Submitted by: Reviewed by: git-svn-id: https://svn.apache.org/repos/asf/ant/core/trunk@273709 13f79535-47bb-0310-9956-ffa450edef68
23 years ago
"Dynamic properties" and a bit more. This is "slightly" different from embed - if dynamic properties will be accepted in 1.6, it is better to do it right. Embed uses few hacks to trick the ProjectHelper. PropertyHelper includes all the code related with property manipulation from Project (cut&paste). I added a very simple hook mechanism ( Filter/Valve like ) for the most common operations. The API is obviously far from final - someone who really understand "user" and "inherited" properties should review it and make few changes. In Project, all properties fields are private - so all can be removed. The methods related with properties will just delegate to PropertyHelper. From a user point of view - no visible change ( hopefully :-). Even grant will continue to work ( but won't be able to use the new features ). Benefits: - cleanup of Project. Less code and better organised. - Property handling will hopefully be cleaner too - we get to add APIs for namespace support, and maybe support non-string properties ( JSP-EL like - that needs to be disussed, but IMO it would be very helpfull ). While refs are Objects, the main distinction is imutability. Also: - apps embeding or extending ant can fully customize _all_ aspects of property processing, including ${} replacement and even the syntax. - it should be very easy to hook a different storage mechanism ( i.e. integrated with the embeding app, without requiring copy of properties ). - it should be possible to avoid copy when creating execution frames ( by using a chain that keeps changes and delegates getters ). - dynamic properties support ( my original itch :-) Please wait few days before firing, it seems all tests are passing and gump works - but I'm sure there are few problems :-) ( I'll commit the change in Project later today ) PR: Obtained from: Submitted by: Reviewed by: git-svn-id: https://svn.apache.org/repos/asf/ant/core/trunk@273709 13f79535-47bb-0310-9956-ffa450edef68
23 years ago
"Dynamic properties" and a bit more. This is "slightly" different from embed - if dynamic properties will be accepted in 1.6, it is better to do it right. Embed uses few hacks to trick the ProjectHelper. PropertyHelper includes all the code related with property manipulation from Project (cut&paste). I added a very simple hook mechanism ( Filter/Valve like ) for the most common operations. The API is obviously far from final - someone who really understand "user" and "inherited" properties should review it and make few changes. In Project, all properties fields are private - so all can be removed. The methods related with properties will just delegate to PropertyHelper. From a user point of view - no visible change ( hopefully :-). Even grant will continue to work ( but won't be able to use the new features ). Benefits: - cleanup of Project. Less code and better organised. - Property handling will hopefully be cleaner too - we get to add APIs for namespace support, and maybe support non-string properties ( JSP-EL like - that needs to be disussed, but IMO it would be very helpfull ). While refs are Objects, the main distinction is imutability. Also: - apps embeding or extending ant can fully customize _all_ aspects of property processing, including ${} replacement and even the syntax. - it should be very easy to hook a different storage mechanism ( i.e. integrated with the embeding app, without requiring copy of properties ). - it should be possible to avoid copy when creating execution frames ( by using a chain that keeps changes and delegates getters ). - dynamic properties support ( my original itch :-) Please wait few days before firing, it seems all tests are passing and gump works - but I'm sure there are few problems :-) ( I'll commit the change in Project later today ) PR: Obtained from: Submitted by: Reviewed by: git-svn-id: https://svn.apache.org/repos/asf/ant/core/trunk@273709 13f79535-47bb-0310-9956-ffa450edef68
23 years ago
"Dynamic properties" and a bit more. This is "slightly" different from embed - if dynamic properties will be accepted in 1.6, it is better to do it right. Embed uses few hacks to trick the ProjectHelper. PropertyHelper includes all the code related with property manipulation from Project (cut&paste). I added a very simple hook mechanism ( Filter/Valve like ) for the most common operations. The API is obviously far from final - someone who really understand "user" and "inherited" properties should review it and make few changes. In Project, all properties fields are private - so all can be removed. The methods related with properties will just delegate to PropertyHelper. From a user point of view - no visible change ( hopefully :-). Even grant will continue to work ( but won't be able to use the new features ). Benefits: - cleanup of Project. Less code and better organised. - Property handling will hopefully be cleaner too - we get to add APIs for namespace support, and maybe support non-string properties ( JSP-EL like - that needs to be disussed, but IMO it would be very helpfull ). While refs are Objects, the main distinction is imutability. Also: - apps embeding or extending ant can fully customize _all_ aspects of property processing, including ${} replacement and even the syntax. - it should be very easy to hook a different storage mechanism ( i.e. integrated with the embeding app, without requiring copy of properties ). - it should be possible to avoid copy when creating execution frames ( by using a chain that keeps changes and delegates getters ). - dynamic properties support ( my original itch :-) Please wait few days before firing, it seems all tests are passing and gump works - but I'm sure there are few problems :-) ( I'll commit the change in Project later today ) PR: Obtained from: Submitted by: Reviewed by: git-svn-id: https://svn.apache.org/repos/asf/ant/core/trunk@273709 13f79535-47bb-0310-9956-ffa450edef68
23 years ago
"Dynamic properties" and a bit more. This is "slightly" different from embed - if dynamic properties will be accepted in 1.6, it is better to do it right. Embed uses few hacks to trick the ProjectHelper. PropertyHelper includes all the code related with property manipulation from Project (cut&paste). I added a very simple hook mechanism ( Filter/Valve like ) for the most common operations. The API is obviously far from final - someone who really understand "user" and "inherited" properties should review it and make few changes. In Project, all properties fields are private - so all can be removed. The methods related with properties will just delegate to PropertyHelper. From a user point of view - no visible change ( hopefully :-). Even grant will continue to work ( but won't be able to use the new features ). Benefits: - cleanup of Project. Less code and better organised. - Property handling will hopefully be cleaner too - we get to add APIs for namespace support, and maybe support non-string properties ( JSP-EL like - that needs to be disussed, but IMO it would be very helpfull ). While refs are Objects, the main distinction is imutability. Also: - apps embeding or extending ant can fully customize _all_ aspects of property processing, including ${} replacement and even the syntax. - it should be very easy to hook a different storage mechanism ( i.e. integrated with the embeding app, without requiring copy of properties ). - it should be possible to avoid copy when creating execution frames ( by using a chain that keeps changes and delegates getters ). - dynamic properties support ( my original itch :-) Please wait few days before firing, it seems all tests are passing and gump works - but I'm sure there are few problems :-) ( I'll commit the change in Project later today ) PR: Obtained from: Submitted by: Reviewed by: git-svn-id: https://svn.apache.org/repos/asf/ant/core/trunk@273709 13f79535-47bb-0310-9956-ffa450edef68
23 years ago
"Dynamic properties" and a bit more. This is "slightly" different from embed - if dynamic properties will be accepted in 1.6, it is better to do it right. Embed uses few hacks to trick the ProjectHelper. PropertyHelper includes all the code related with property manipulation from Project (cut&paste). I added a very simple hook mechanism ( Filter/Valve like ) for the most common operations. The API is obviously far from final - someone who really understand "user" and "inherited" properties should review it and make few changes. In Project, all properties fields are private - so all can be removed. The methods related with properties will just delegate to PropertyHelper. From a user point of view - no visible change ( hopefully :-). Even grant will continue to work ( but won't be able to use the new features ). Benefits: - cleanup of Project. Less code and better organised. - Property handling will hopefully be cleaner too - we get to add APIs for namespace support, and maybe support non-string properties ( JSP-EL like - that needs to be disussed, but IMO it would be very helpfull ). While refs are Objects, the main distinction is imutability. Also: - apps embeding or extending ant can fully customize _all_ aspects of property processing, including ${} replacement and even the syntax. - it should be very easy to hook a different storage mechanism ( i.e. integrated with the embeding app, without requiring copy of properties ). - it should be possible to avoid copy when creating execution frames ( by using a chain that keeps changes and delegates getters ). - dynamic properties support ( my original itch :-) Please wait few days before firing, it seems all tests are passing and gump works - but I'm sure there are few problems :-) ( I'll commit the change in Project later today ) PR: Obtained from: Submitted by: Reviewed by: git-svn-id: https://svn.apache.org/repos/asf/ant/core/trunk@273709 13f79535-47bb-0310-9956-ffa450edef68
23 years ago
"Dynamic properties" and a bit more. This is "slightly" different from embed - if dynamic properties will be accepted in 1.6, it is better to do it right. Embed uses few hacks to trick the ProjectHelper. PropertyHelper includes all the code related with property manipulation from Project (cut&paste). I added a very simple hook mechanism ( Filter/Valve like ) for the most common operations. The API is obviously far from final - someone who really understand "user" and "inherited" properties should review it and make few changes. In Project, all properties fields are private - so all can be removed. The methods related with properties will just delegate to PropertyHelper. From a user point of view - no visible change ( hopefully :-). Even grant will continue to work ( but won't be able to use the new features ). Benefits: - cleanup of Project. Less code and better organised. - Property handling will hopefully be cleaner too - we get to add APIs for namespace support, and maybe support non-string properties ( JSP-EL like - that needs to be disussed, but IMO it would be very helpfull ). While refs are Objects, the main distinction is imutability. Also: - apps embeding or extending ant can fully customize _all_ aspects of property processing, including ${} replacement and even the syntax. - it should be very easy to hook a different storage mechanism ( i.e. integrated with the embeding app, without requiring copy of properties ). - it should be possible to avoid copy when creating execution frames ( by using a chain that keeps changes and delegates getters ). - dynamic properties support ( my original itch :-) Please wait few days before firing, it seems all tests are passing and gump works - but I'm sure there are few problems :-) ( I'll commit the change in Project later today ) PR: Obtained from: Submitted by: Reviewed by: git-svn-id: https://svn.apache.org/repos/asf/ant/core/trunk@273709 13f79535-47bb-0310-9956-ffa450edef68
23 years ago
"Dynamic properties" and a bit more. This is "slightly" different from embed - if dynamic properties will be accepted in 1.6, it is better to do it right. Embed uses few hacks to trick the ProjectHelper. PropertyHelper includes all the code related with property manipulation from Project (cut&paste). I added a very simple hook mechanism ( Filter/Valve like ) for the most common operations. The API is obviously far from final - someone who really understand "user" and "inherited" properties should review it and make few changes. In Project, all properties fields are private - so all can be removed. The methods related with properties will just delegate to PropertyHelper. From a user point of view - no visible change ( hopefully :-). Even grant will continue to work ( but won't be able to use the new features ). Benefits: - cleanup of Project. Less code and better organised. - Property handling will hopefully be cleaner too - we get to add APIs for namespace support, and maybe support non-string properties ( JSP-EL like - that needs to be disussed, but IMO it would be very helpfull ). While refs are Objects, the main distinction is imutability. Also: - apps embeding or extending ant can fully customize _all_ aspects of property processing, including ${} replacement and even the syntax. - it should be very easy to hook a different storage mechanism ( i.e. integrated with the embeding app, without requiring copy of properties ). - it should be possible to avoid copy when creating execution frames ( by using a chain that keeps changes and delegates getters ). - dynamic properties support ( my original itch :-) Please wait few days before firing, it seems all tests are passing and gump works - but I'm sure there are few problems :-) ( I'll commit the change in Project later today ) PR: Obtained from: Submitted by: Reviewed by: git-svn-id: https://svn.apache.org/repos/asf/ant/core/trunk@273709 13f79535-47bb-0310-9956-ffa450edef68
23 years ago
"Dynamic properties" and a bit more. This is "slightly" different from embed - if dynamic properties will be accepted in 1.6, it is better to do it right. Embed uses few hacks to trick the ProjectHelper. PropertyHelper includes all the code related with property manipulation from Project (cut&paste). I added a very simple hook mechanism ( Filter/Valve like ) for the most common operations. The API is obviously far from final - someone who really understand "user" and "inherited" properties should review it and make few changes. In Project, all properties fields are private - so all can be removed. The methods related with properties will just delegate to PropertyHelper. From a user point of view - no visible change ( hopefully :-). Even grant will continue to work ( but won't be able to use the new features ). Benefits: - cleanup of Project. Less code and better organised. - Property handling will hopefully be cleaner too - we get to add APIs for namespace support, and maybe support non-string properties ( JSP-EL like - that needs to be disussed, but IMO it would be very helpfull ). While refs are Objects, the main distinction is imutability. Also: - apps embeding or extending ant can fully customize _all_ aspects of property processing, including ${} replacement and even the syntax. - it should be very easy to hook a different storage mechanism ( i.e. integrated with the embeding app, without requiring copy of properties ). - it should be possible to avoid copy when creating execution frames ( by using a chain that keeps changes and delegates getters ). - dynamic properties support ( my original itch :-) Please wait few days before firing, it seems all tests are passing and gump works - but I'm sure there are few problems :-) ( I'll commit the change in Project later today ) PR: Obtained from: Submitted by: Reviewed by: git-svn-id: https://svn.apache.org/repos/asf/ant/core/trunk@273709 13f79535-47bb-0310-9956-ffa450edef68
23 years ago
"Dynamic properties" and a bit more. This is "slightly" different from embed - if dynamic properties will be accepted in 1.6, it is better to do it right. Embed uses few hacks to trick the ProjectHelper. PropertyHelper includes all the code related with property manipulation from Project (cut&paste). I added a very simple hook mechanism ( Filter/Valve like ) for the most common operations. The API is obviously far from final - someone who really understand "user" and "inherited" properties should review it and make few changes. In Project, all properties fields are private - so all can be removed. The methods related with properties will just delegate to PropertyHelper. From a user point of view - no visible change ( hopefully :-). Even grant will continue to work ( but won't be able to use the new features ). Benefits: - cleanup of Project. Less code and better organised. - Property handling will hopefully be cleaner too - we get to add APIs for namespace support, and maybe support non-string properties ( JSP-EL like - that needs to be disussed, but IMO it would be very helpfull ). While refs are Objects, the main distinction is imutability. Also: - apps embeding or extending ant can fully customize _all_ aspects of property processing, including ${} replacement and even the syntax. - it should be very easy to hook a different storage mechanism ( i.e. integrated with the embeding app, without requiring copy of properties ). - it should be possible to avoid copy when creating execution frames ( by using a chain that keeps changes and delegates getters ). - dynamic properties support ( my original itch :-) Please wait few days before firing, it seems all tests are passing and gump works - but I'm sure there are few problems :-) ( I'll commit the change in Project later today ) PR: Obtained from: Submitted by: Reviewed by: git-svn-id: https://svn.apache.org/repos/asf/ant/core/trunk@273709 13f79535-47bb-0310-9956-ffa450edef68
23 years ago
"Dynamic properties" and a bit more. This is "slightly" different from embed - if dynamic properties will be accepted in 1.6, it is better to do it right. Embed uses few hacks to trick the ProjectHelper. PropertyHelper includes all the code related with property manipulation from Project (cut&paste). I added a very simple hook mechanism ( Filter/Valve like ) for the most common operations. The API is obviously far from final - someone who really understand "user" and "inherited" properties should review it and make few changes. In Project, all properties fields are private - so all can be removed. The methods related with properties will just delegate to PropertyHelper. From a user point of view - no visible change ( hopefully :-). Even grant will continue to work ( but won't be able to use the new features ). Benefits: - cleanup of Project. Less code and better organised. - Property handling will hopefully be cleaner too - we get to add APIs for namespace support, and maybe support non-string properties ( JSP-EL like - that needs to be disussed, but IMO it would be very helpfull ). While refs are Objects, the main distinction is imutability. Also: - apps embeding or extending ant can fully customize _all_ aspects of property processing, including ${} replacement and even the syntax. - it should be very easy to hook a different storage mechanism ( i.e. integrated with the embeding app, without requiring copy of properties ). - it should be possible to avoid copy when creating execution frames ( by using a chain that keeps changes and delegates getters ). - dynamic properties support ( my original itch :-) Please wait few days before firing, it seems all tests are passing and gump works - but I'm sure there are few problems :-) ( I'll commit the change in Project later today ) PR: Obtained from: Submitted by: Reviewed by: git-svn-id: https://svn.apache.org/repos/asf/ant/core/trunk@273709 13f79535-47bb-0310-9956-ffa450edef68
23 years ago
"Dynamic properties" and a bit more. This is "slightly" different from embed - if dynamic properties will be accepted in 1.6, it is better to do it right. Embed uses few hacks to trick the ProjectHelper. PropertyHelper includes all the code related with property manipulation from Project (cut&paste). I added a very simple hook mechanism ( Filter/Valve like ) for the most common operations. The API is obviously far from final - someone who really understand "user" and "inherited" properties should review it and make few changes. In Project, all properties fields are private - so all can be removed. The methods related with properties will just delegate to PropertyHelper. From a user point of view - no visible change ( hopefully :-). Even grant will continue to work ( but won't be able to use the new features ). Benefits: - cleanup of Project. Less code and better organised. - Property handling will hopefully be cleaner too - we get to add APIs for namespace support, and maybe support non-string properties ( JSP-EL like - that needs to be disussed, but IMO it would be very helpfull ). While refs are Objects, the main distinction is imutability. Also: - apps embeding or extending ant can fully customize _all_ aspects of property processing, including ${} replacement and even the syntax. - it should be very easy to hook a different storage mechanism ( i.e. integrated with the embeding app, without requiring copy of properties ). - it should be possible to avoid copy when creating execution frames ( by using a chain that keeps changes and delegates getters ). - dynamic properties support ( my original itch :-) Please wait few days before firing, it seems all tests are passing and gump works - but I'm sure there are few problems :-) ( I'll commit the change in Project later today ) PR: Obtained from: Submitted by: Reviewed by: git-svn-id: https://svn.apache.org/repos/asf/ant/core/trunk@273709 13f79535-47bb-0310-9956-ffa450edef68
23 years ago
"Dynamic properties" and a bit more. This is "slightly" different from embed - if dynamic properties will be accepted in 1.6, it is better to do it right. Embed uses few hacks to trick the ProjectHelper. PropertyHelper includes all the code related with property manipulation from Project (cut&paste). I added a very simple hook mechanism ( Filter/Valve like ) for the most common operations. The API is obviously far from final - someone who really understand "user" and "inherited" properties should review it and make few changes. In Project, all properties fields are private - so all can be removed. The methods related with properties will just delegate to PropertyHelper. From a user point of view - no visible change ( hopefully :-). Even grant will continue to work ( but won't be able to use the new features ). Benefits: - cleanup of Project. Less code and better organised. - Property handling will hopefully be cleaner too - we get to add APIs for namespace support, and maybe support non-string properties ( JSP-EL like - that needs to be disussed, but IMO it would be very helpfull ). While refs are Objects, the main distinction is imutability. Also: - apps embeding or extending ant can fully customize _all_ aspects of property processing, including ${} replacement and even the syntax. - it should be very easy to hook a different storage mechanism ( i.e. integrated with the embeding app, without requiring copy of properties ). - it should be possible to avoid copy when creating execution frames ( by using a chain that keeps changes and delegates getters ). - dynamic properties support ( my original itch :-) Please wait few days before firing, it seems all tests are passing and gump works - but I'm sure there are few problems :-) ( I'll commit the change in Project later today ) PR: Obtained from: Submitted by: Reviewed by: git-svn-id: https://svn.apache.org/repos/asf/ant/core/trunk@273709 13f79535-47bb-0310-9956-ffa450edef68
23 years ago
"Dynamic properties" and a bit more. This is "slightly" different from embed - if dynamic properties will be accepted in 1.6, it is better to do it right. Embed uses few hacks to trick the ProjectHelper. PropertyHelper includes all the code related with property manipulation from Project (cut&paste). I added a very simple hook mechanism ( Filter/Valve like ) for the most common operations. The API is obviously far from final - someone who really understand "user" and "inherited" properties should review it and make few changes. In Project, all properties fields are private - so all can be removed. The methods related with properties will just delegate to PropertyHelper. From a user point of view - no visible change ( hopefully :-). Even grant will continue to work ( but won't be able to use the new features ). Benefits: - cleanup of Project. Less code and better organised. - Property handling will hopefully be cleaner too - we get to add APIs for namespace support, and maybe support non-string properties ( JSP-EL like - that needs to be disussed, but IMO it would be very helpfull ). While refs are Objects, the main distinction is imutability. Also: - apps embeding or extending ant can fully customize _all_ aspects of property processing, including ${} replacement and even the syntax. - it should be very easy to hook a different storage mechanism ( i.e. integrated with the embeding app, without requiring copy of properties ). - it should be possible to avoid copy when creating execution frames ( by using a chain that keeps changes and delegates getters ). - dynamic properties support ( my original itch :-) Please wait few days before firing, it seems all tests are passing and gump works - but I'm sure there are few problems :-) ( I'll commit the change in Project later today ) PR: Obtained from: Submitted by: Reviewed by: git-svn-id: https://svn.apache.org/repos/asf/ant/core/trunk@273709 13f79535-47bb-0310-9956-ffa450edef68
23 years ago
"Dynamic properties" and a bit more. This is "slightly" different from embed - if dynamic properties will be accepted in 1.6, it is better to do it right. Embed uses few hacks to trick the ProjectHelper. PropertyHelper includes all the code related with property manipulation from Project (cut&paste). I added a very simple hook mechanism ( Filter/Valve like ) for the most common operations. The API is obviously far from final - someone who really understand "user" and "inherited" properties should review it and make few changes. In Project, all properties fields are private - so all can be removed. The methods related with properties will just delegate to PropertyHelper. From a user point of view - no visible change ( hopefully :-). Even grant will continue to work ( but won't be able to use the new features ). Benefits: - cleanup of Project. Less code and better organised. - Property handling will hopefully be cleaner too - we get to add APIs for namespace support, and maybe support non-string properties ( JSP-EL like - that needs to be disussed, but IMO it would be very helpfull ). While refs are Objects, the main distinction is imutability. Also: - apps embeding or extending ant can fully customize _all_ aspects of property processing, including ${} replacement and even the syntax. - it should be very easy to hook a different storage mechanism ( i.e. integrated with the embeding app, without requiring copy of properties ). - it should be possible to avoid copy when creating execution frames ( by using a chain that keeps changes and delegates getters ). - dynamic properties support ( my original itch :-) Please wait few days before firing, it seems all tests are passing and gump works - but I'm sure there are few problems :-) ( I'll commit the change in Project later today ) PR: Obtained from: Submitted by: Reviewed by: git-svn-id: https://svn.apache.org/repos/asf/ant/core/trunk@273709 13f79535-47bb-0310-9956-ffa450edef68
23 years ago
"Dynamic properties" and a bit more. This is "slightly" different from embed - if dynamic properties will be accepted in 1.6, it is better to do it right. Embed uses few hacks to trick the ProjectHelper. PropertyHelper includes all the code related with property manipulation from Project (cut&paste). I added a very simple hook mechanism ( Filter/Valve like ) for the most common operations. The API is obviously far from final - someone who really understand "user" and "inherited" properties should review it and make few changes. In Project, all properties fields are private - so all can be removed. The methods related with properties will just delegate to PropertyHelper. From a user point of view - no visible change ( hopefully :-). Even grant will continue to work ( but won't be able to use the new features ). Benefits: - cleanup of Project. Less code and better organised. - Property handling will hopefully be cleaner too - we get to add APIs for namespace support, and maybe support non-string properties ( JSP-EL like - that needs to be disussed, but IMO it would be very helpfull ). While refs are Objects, the main distinction is imutability. Also: - apps embeding or extending ant can fully customize _all_ aspects of property processing, including ${} replacement and even the syntax. - it should be very easy to hook a different storage mechanism ( i.e. integrated with the embeding app, without requiring copy of properties ). - it should be possible to avoid copy when creating execution frames ( by using a chain that keeps changes and delegates getters ). - dynamic properties support ( my original itch :-) Please wait few days before firing, it seems all tests are passing and gump works - but I'm sure there are few problems :-) ( I'll commit the change in Project later today ) PR: Obtained from: Submitted by: Reviewed by: git-svn-id: https://svn.apache.org/repos/asf/ant/core/trunk@273709 13f79535-47bb-0310-9956-ffa450edef68
23 years ago
"Dynamic properties" and a bit more. This is "slightly" different from embed - if dynamic properties will be accepted in 1.6, it is better to do it right. Embed uses few hacks to trick the ProjectHelper. PropertyHelper includes all the code related with property manipulation from Project (cut&paste). I added a very simple hook mechanism ( Filter/Valve like ) for the most common operations. The API is obviously far from final - someone who really understand "user" and "inherited" properties should review it and make few changes. In Project, all properties fields are private - so all can be removed. The methods related with properties will just delegate to PropertyHelper. From a user point of view - no visible change ( hopefully :-). Even grant will continue to work ( but won't be able to use the new features ). Benefits: - cleanup of Project. Less code and better organised. - Property handling will hopefully be cleaner too - we get to add APIs for namespace support, and maybe support non-string properties ( JSP-EL like - that needs to be disussed, but IMO it would be very helpfull ). While refs are Objects, the main distinction is imutability. Also: - apps embeding or extending ant can fully customize _all_ aspects of property processing, including ${} replacement and even the syntax. - it should be very easy to hook a different storage mechanism ( i.e. integrated with the embeding app, without requiring copy of properties ). - it should be possible to avoid copy when creating execution frames ( by using a chain that keeps changes and delegates getters ). - dynamic properties support ( my original itch :-) Please wait few days before firing, it seems all tests are passing and gump works - but I'm sure there are few problems :-) ( I'll commit the change in Project later today ) PR: Obtained from: Submitted by: Reviewed by: git-svn-id: https://svn.apache.org/repos/asf/ant/core/trunk@273709 13f79535-47bb-0310-9956-ffa450edef68
23 years ago
"Dynamic properties" and a bit more. This is "slightly" different from embed - if dynamic properties will be accepted in 1.6, it is better to do it right. Embed uses few hacks to trick the ProjectHelper. PropertyHelper includes all the code related with property manipulation from Project (cut&paste). I added a very simple hook mechanism ( Filter/Valve like ) for the most common operations. The API is obviously far from final - someone who really understand "user" and "inherited" properties should review it and make few changes. In Project, all properties fields are private - so all can be removed. The methods related with properties will just delegate to PropertyHelper. From a user point of view - no visible change ( hopefully :-). Even grant will continue to work ( but won't be able to use the new features ). Benefits: - cleanup of Project. Less code and better organised. - Property handling will hopefully be cleaner too - we get to add APIs for namespace support, and maybe support non-string properties ( JSP-EL like - that needs to be disussed, but IMO it would be very helpfull ). While refs are Objects, the main distinction is imutability. Also: - apps embeding or extending ant can fully customize _all_ aspects of property processing, including ${} replacement and even the syntax. - it should be very easy to hook a different storage mechanism ( i.e. integrated with the embeding app, without requiring copy of properties ). - it should be possible to avoid copy when creating execution frames ( by using a chain that keeps changes and delegates getters ). - dynamic properties support ( my original itch :-) Please wait few days before firing, it seems all tests are passing and gump works - but I'm sure there are few problems :-) ( I'll commit the change in Project later today ) PR: Obtained from: Submitted by: Reviewed by: git-svn-id: https://svn.apache.org/repos/asf/ant/core/trunk@273709 13f79535-47bb-0310-9956-ffa450edef68
23 years ago
"Dynamic properties" and a bit more. This is "slightly" different from embed - if dynamic properties will be accepted in 1.6, it is better to do it right. Embed uses few hacks to trick the ProjectHelper. PropertyHelper includes all the code related with property manipulation from Project (cut&paste). I added a very simple hook mechanism ( Filter/Valve like ) for the most common operations. The API is obviously far from final - someone who really understand "user" and "inherited" properties should review it and make few changes. In Project, all properties fields are private - so all can be removed. The methods related with properties will just delegate to PropertyHelper. From a user point of view - no visible change ( hopefully :-). Even grant will continue to work ( but won't be able to use the new features ). Benefits: - cleanup of Project. Less code and better organised. - Property handling will hopefully be cleaner too - we get to add APIs for namespace support, and maybe support non-string properties ( JSP-EL like - that needs to be disussed, but IMO it would be very helpfull ). While refs are Objects, the main distinction is imutability. Also: - apps embeding or extending ant can fully customize _all_ aspects of property processing, including ${} replacement and even the syntax. - it should be very easy to hook a different storage mechanism ( i.e. integrated with the embeding app, without requiring copy of properties ). - it should be possible to avoid copy when creating execution frames ( by using a chain that keeps changes and delegates getters ). - dynamic properties support ( my original itch :-) Please wait few days before firing, it seems all tests are passing and gump works - but I'm sure there are few problems :-) ( I'll commit the change in Project later today ) PR: Obtained from: Submitted by: Reviewed by: git-svn-id: https://svn.apache.org/repos/asf/ant/core/trunk@273709 13f79535-47bb-0310-9956-ffa450edef68
23 years ago
"Dynamic properties" and a bit more. This is "slightly" different from embed - if dynamic properties will be accepted in 1.6, it is better to do it right. Embed uses few hacks to trick the ProjectHelper. PropertyHelper includes all the code related with property manipulation from Project (cut&paste). I added a very simple hook mechanism ( Filter/Valve like ) for the most common operations. The API is obviously far from final - someone who really understand "user" and "inherited" properties should review it and make few changes. In Project, all properties fields are private - so all can be removed. The methods related with properties will just delegate to PropertyHelper. From a user point of view - no visible change ( hopefully :-). Even grant will continue to work ( but won't be able to use the new features ). Benefits: - cleanup of Project. Less code and better organised. - Property handling will hopefully be cleaner too - we get to add APIs for namespace support, and maybe support non-string properties ( JSP-EL like - that needs to be disussed, but IMO it would be very helpfull ). While refs are Objects, the main distinction is imutability. Also: - apps embeding or extending ant can fully customize _all_ aspects of property processing, including ${} replacement and even the syntax. - it should be very easy to hook a different storage mechanism ( i.e. integrated with the embeding app, without requiring copy of properties ). - it should be possible to avoid copy when creating execution frames ( by using a chain that keeps changes and delegates getters ). - dynamic properties support ( my original itch :-) Please wait few days before firing, it seems all tests are passing and gump works - but I'm sure there are few problems :-) ( I'll commit the change in Project later today ) PR: Obtained from: Submitted by: Reviewed by: git-svn-id: https://svn.apache.org/repos/asf/ant/core/trunk@273709 13f79535-47bb-0310-9956-ffa450edef68
23 years ago
"Dynamic properties" and a bit more. This is "slightly" different from embed - if dynamic properties will be accepted in 1.6, it is better to do it right. Embed uses few hacks to trick the ProjectHelper. PropertyHelper includes all the code related with property manipulation from Project (cut&paste). I added a very simple hook mechanism ( Filter/Valve like ) for the most common operations. The API is obviously far from final - someone who really understand "user" and "inherited" properties should review it and make few changes. In Project, all properties fields are private - so all can be removed. The methods related with properties will just delegate to PropertyHelper. From a user point of view - no visible change ( hopefully :-). Even grant will continue to work ( but won't be able to use the new features ). Benefits: - cleanup of Project. Less code and better organised. - Property handling will hopefully be cleaner too - we get to add APIs for namespace support, and maybe support non-string properties ( JSP-EL like - that needs to be disussed, but IMO it would be very helpfull ). While refs are Objects, the main distinction is imutability. Also: - apps embeding or extending ant can fully customize _all_ aspects of property processing, including ${} replacement and even the syntax. - it should be very easy to hook a different storage mechanism ( i.e. integrated with the embeding app, without requiring copy of properties ). - it should be possible to avoid copy when creating execution frames ( by using a chain that keeps changes and delegates getters ). - dynamic properties support ( my original itch :-) Please wait few days before firing, it seems all tests are passing and gump works - but I'm sure there are few problems :-) ( I'll commit the change in Project later today ) PR: Obtained from: Submitted by: Reviewed by: git-svn-id: https://svn.apache.org/repos/asf/ant/core/trunk@273709 13f79535-47bb-0310-9956-ffa450edef68
23 years ago
"Dynamic properties" and a bit more. This is "slightly" different from embed - if dynamic properties will be accepted in 1.6, it is better to do it right. Embed uses few hacks to trick the ProjectHelper. PropertyHelper includes all the code related with property manipulation from Project (cut&paste). I added a very simple hook mechanism ( Filter/Valve like ) for the most common operations. The API is obviously far from final - someone who really understand "user" and "inherited" properties should review it and make few changes. In Project, all properties fields are private - so all can be removed. The methods related with properties will just delegate to PropertyHelper. From a user point of view - no visible change ( hopefully :-). Even grant will continue to work ( but won't be able to use the new features ). Benefits: - cleanup of Project. Less code and better organised. - Property handling will hopefully be cleaner too - we get to add APIs for namespace support, and maybe support non-string properties ( JSP-EL like - that needs to be disussed, but IMO it would be very helpfull ). While refs are Objects, the main distinction is imutability. Also: - apps embeding or extending ant can fully customize _all_ aspects of property processing, including ${} replacement and even the syntax. - it should be very easy to hook a different storage mechanism ( i.e. integrated with the embeding app, without requiring copy of properties ). - it should be possible to avoid copy when creating execution frames ( by using a chain that keeps changes and delegates getters ). - dynamic properties support ( my original itch :-) Please wait few days before firing, it seems all tests are passing and gump works - but I'm sure there are few problems :-) ( I'll commit the change in Project later today ) PR: Obtained from: Submitted by: Reviewed by: git-svn-id: https://svn.apache.org/repos/asf/ant/core/trunk@273709 13f79535-47bb-0310-9956-ffa450edef68
23 years ago
"Dynamic properties" and a bit more. This is "slightly" different from embed - if dynamic properties will be accepted in 1.6, it is better to do it right. Embed uses few hacks to trick the ProjectHelper. PropertyHelper includes all the code related with property manipulation from Project (cut&paste). I added a very simple hook mechanism ( Filter/Valve like ) for the most common operations. The API is obviously far from final - someone who really understand "user" and "inherited" properties should review it and make few changes. In Project, all properties fields are private - so all can be removed. The methods related with properties will just delegate to PropertyHelper. From a user point of view - no visible change ( hopefully :-). Even grant will continue to work ( but won't be able to use the new features ). Benefits: - cleanup of Project. Less code and better organised. - Property handling will hopefully be cleaner too - we get to add APIs for namespace support, and maybe support non-string properties ( JSP-EL like - that needs to be disussed, but IMO it would be very helpfull ). While refs are Objects, the main distinction is imutability. Also: - apps embeding or extending ant can fully customize _all_ aspects of property processing, including ${} replacement and even the syntax. - it should be very easy to hook a different storage mechanism ( i.e. integrated with the embeding app, without requiring copy of properties ). - it should be possible to avoid copy when creating execution frames ( by using a chain that keeps changes and delegates getters ). - dynamic properties support ( my original itch :-) Please wait few days before firing, it seems all tests are passing and gump works - but I'm sure there are few problems :-) ( I'll commit the change in Project later today ) PR: Obtained from: Submitted by: Reviewed by: git-svn-id: https://svn.apache.org/repos/asf/ant/core/trunk@273709 13f79535-47bb-0310-9956-ffa450edef68
23 years ago
"Dynamic properties" and a bit more. This is "slightly" different from embed - if dynamic properties will be accepted in 1.6, it is better to do it right. Embed uses few hacks to trick the ProjectHelper. PropertyHelper includes all the code related with property manipulation from Project (cut&paste). I added a very simple hook mechanism ( Filter/Valve like ) for the most common operations. The API is obviously far from final - someone who really understand "user" and "inherited" properties should review it and make few changes. In Project, all properties fields are private - so all can be removed. The methods related with properties will just delegate to PropertyHelper. From a user point of view - no visible change ( hopefully :-). Even grant will continue to work ( but won't be able to use the new features ). Benefits: - cleanup of Project. Less code and better organised. - Property handling will hopefully be cleaner too - we get to add APIs for namespace support, and maybe support non-string properties ( JSP-EL like - that needs to be disussed, but IMO it would be very helpfull ). While refs are Objects, the main distinction is imutability. Also: - apps embeding or extending ant can fully customize _all_ aspects of property processing, including ${} replacement and even the syntax. - it should be very easy to hook a different storage mechanism ( i.e. integrated with the embeding app, without requiring copy of properties ). - it should be possible to avoid copy when creating execution frames ( by using a chain that keeps changes and delegates getters ). - dynamic properties support ( my original itch :-) Please wait few days before firing, it seems all tests are passing and gump works - but I'm sure there are few problems :-) ( I'll commit the change in Project later today ) PR: Obtained from: Submitted by: Reviewed by: git-svn-id: https://svn.apache.org/repos/asf/ant/core/trunk@273709 13f79535-47bb-0310-9956-ffa450edef68
23 years ago
"Dynamic properties" and a bit more. This is "slightly" different from embed - if dynamic properties will be accepted in 1.6, it is better to do it right. Embed uses few hacks to trick the ProjectHelper. PropertyHelper includes all the code related with property manipulation from Project (cut&paste). I added a very simple hook mechanism ( Filter/Valve like ) for the most common operations. The API is obviously far from final - someone who really understand "user" and "inherited" properties should review it and make few changes. In Project, all properties fields are private - so all can be removed. The methods related with properties will just delegate to PropertyHelper. From a user point of view - no visible change ( hopefully :-). Even grant will continue to work ( but won't be able to use the new features ). Benefits: - cleanup of Project. Less code and better organised. - Property handling will hopefully be cleaner too - we get to add APIs for namespace support, and maybe support non-string properties ( JSP-EL like - that needs to be disussed, but IMO it would be very helpfull ). While refs are Objects, the main distinction is imutability. Also: - apps embeding or extending ant can fully customize _all_ aspects of property processing, including ${} replacement and even the syntax. - it should be very easy to hook a different storage mechanism ( i.e. integrated with the embeding app, without requiring copy of properties ). - it should be possible to avoid copy when creating execution frames ( by using a chain that keeps changes and delegates getters ). - dynamic properties support ( my original itch :-) Please wait few days before firing, it seems all tests are passing and gump works - but I'm sure there are few problems :-) ( I'll commit the change in Project later today ) PR: Obtained from: Submitted by: Reviewed by: git-svn-id: https://svn.apache.org/repos/asf/ant/core/trunk@273709 13f79535-47bb-0310-9956-ffa450edef68
23 years ago
"Dynamic properties" and a bit more. This is "slightly" different from embed - if dynamic properties will be accepted in 1.6, it is better to do it right. Embed uses few hacks to trick the ProjectHelper. PropertyHelper includes all the code related with property manipulation from Project (cut&paste). I added a very simple hook mechanism ( Filter/Valve like ) for the most common operations. The API is obviously far from final - someone who really understand "user" and "inherited" properties should review it and make few changes. In Project, all properties fields are private - so all can be removed. The methods related with properties will just delegate to PropertyHelper. From a user point of view - no visible change ( hopefully :-). Even grant will continue to work ( but won't be able to use the new features ). Benefits: - cleanup of Project. Less code and better organised. - Property handling will hopefully be cleaner too - we get to add APIs for namespace support, and maybe support non-string properties ( JSP-EL like - that needs to be disussed, but IMO it would be very helpfull ). While refs are Objects, the main distinction is imutability. Also: - apps embeding or extending ant can fully customize _all_ aspects of property processing, including ${} replacement and even the syntax. - it should be very easy to hook a different storage mechanism ( i.e. integrated with the embeding app, without requiring copy of properties ). - it should be possible to avoid copy when creating execution frames ( by using a chain that keeps changes and delegates getters ). - dynamic properties support ( my original itch :-) Please wait few days before firing, it seems all tests are passing and gump works - but I'm sure there are few problems :-) ( I'll commit the change in Project later today ) PR: Obtained from: Submitted by: Reviewed by: git-svn-id: https://svn.apache.org/repos/asf/ant/core/trunk@273709 13f79535-47bb-0310-9956-ffa450edef68
23 years ago
"Dynamic properties" and a bit more. This is "slightly" different from embed - if dynamic properties will be accepted in 1.6, it is better to do it right. Embed uses few hacks to trick the ProjectHelper. PropertyHelper includes all the code related with property manipulation from Project (cut&paste). I added a very simple hook mechanism ( Filter/Valve like ) for the most common operations. The API is obviously far from final - someone who really understand "user" and "inherited" properties should review it and make few changes. In Project, all properties fields are private - so all can be removed. The methods related with properties will just delegate to PropertyHelper. From a user point of view - no visible change ( hopefully :-). Even grant will continue to work ( but won't be able to use the new features ). Benefits: - cleanup of Project. Less code and better organised. - Property handling will hopefully be cleaner too - we get to add APIs for namespace support, and maybe support non-string properties ( JSP-EL like - that needs to be disussed, but IMO it would be very helpfull ). While refs are Objects, the main distinction is imutability. Also: - apps embeding or extending ant can fully customize _all_ aspects of property processing, including ${} replacement and even the syntax. - it should be very easy to hook a different storage mechanism ( i.e. integrated with the embeding app, without requiring copy of properties ). - it should be possible to avoid copy when creating execution frames ( by using a chain that keeps changes and delegates getters ). - dynamic properties support ( my original itch :-) Please wait few days before firing, it seems all tests are passing and gump works - but I'm sure there are few problems :-) ( I'll commit the change in Project later today ) PR: Obtained from: Submitted by: Reviewed by: git-svn-id: https://svn.apache.org/repos/asf/ant/core/trunk@273709 13f79535-47bb-0310-9956-ffa450edef68
23 years ago
"Dynamic properties" and a bit more. This is "slightly" different from embed - if dynamic properties will be accepted in 1.6, it is better to do it right. Embed uses few hacks to trick the ProjectHelper. PropertyHelper includes all the code related with property manipulation from Project (cut&paste). I added a very simple hook mechanism ( Filter/Valve like ) for the most common operations. The API is obviously far from final - someone who really understand "user" and "inherited" properties should review it and make few changes. In Project, all properties fields are private - so all can be removed. The methods related with properties will just delegate to PropertyHelper. From a user point of view - no visible change ( hopefully :-). Even grant will continue to work ( but won't be able to use the new features ). Benefits: - cleanup of Project. Less code and better organised. - Property handling will hopefully be cleaner too - we get to add APIs for namespace support, and maybe support non-string properties ( JSP-EL like - that needs to be disussed, but IMO it would be very helpfull ). While refs are Objects, the main distinction is imutability. Also: - apps embeding or extending ant can fully customize _all_ aspects of property processing, including ${} replacement and even the syntax. - it should be very easy to hook a different storage mechanism ( i.e. integrated with the embeding app, without requiring copy of properties ). - it should be possible to avoid copy when creating execution frames ( by using a chain that keeps changes and delegates getters ). - dynamic properties support ( my original itch :-) Please wait few days before firing, it seems all tests are passing and gump works - but I'm sure there are few problems :-) ( I'll commit the change in Project later today ) PR: Obtained from: Submitted by: Reviewed by: git-svn-id: https://svn.apache.org/repos/asf/ant/core/trunk@273709 13f79535-47bb-0310-9956-ffa450edef68
23 years ago
"Dynamic properties" and a bit more. This is "slightly" different from embed - if dynamic properties will be accepted in 1.6, it is better to do it right. Embed uses few hacks to trick the ProjectHelper. PropertyHelper includes all the code related with property manipulation from Project (cut&paste). I added a very simple hook mechanism ( Filter/Valve like ) for the most common operations. The API is obviously far from final - someone who really understand "user" and "inherited" properties should review it and make few changes. In Project, all properties fields are private - so all can be removed. The methods related with properties will just delegate to PropertyHelper. From a user point of view - no visible change ( hopefully :-). Even grant will continue to work ( but won't be able to use the new features ). Benefits: - cleanup of Project. Less code and better organised. - Property handling will hopefully be cleaner too - we get to add APIs for namespace support, and maybe support non-string properties ( JSP-EL like - that needs to be disussed, but IMO it would be very helpfull ). While refs are Objects, the main distinction is imutability. Also: - apps embeding or extending ant can fully customize _all_ aspects of property processing, including ${} replacement and even the syntax. - it should be very easy to hook a different storage mechanism ( i.e. integrated with the embeding app, without requiring copy of properties ). - it should be possible to avoid copy when creating execution frames ( by using a chain that keeps changes and delegates getters ). - dynamic properties support ( my original itch :-) Please wait few days before firing, it seems all tests are passing and gump works - but I'm sure there are few problems :-) ( I'll commit the change in Project later today ) PR: Obtained from: Submitted by: Reviewed by: git-svn-id: https://svn.apache.org/repos/asf/ant/core/trunk@273709 13f79535-47bb-0310-9956-ffa450edef68
23 years ago
"Dynamic properties" and a bit more. This is "slightly" different from embed - if dynamic properties will be accepted in 1.6, it is better to do it right. Embed uses few hacks to trick the ProjectHelper. PropertyHelper includes all the code related with property manipulation from Project (cut&paste). I added a very simple hook mechanism ( Filter/Valve like ) for the most common operations. The API is obviously far from final - someone who really understand "user" and "inherited" properties should review it and make few changes. In Project, all properties fields are private - so all can be removed. The methods related with properties will just delegate to PropertyHelper. From a user point of view - no visible change ( hopefully :-). Even grant will continue to work ( but won't be able to use the new features ). Benefits: - cleanup of Project. Less code and better organised. - Property handling will hopefully be cleaner too - we get to add APIs for namespace support, and maybe support non-string properties ( JSP-EL like - that needs to be disussed, but IMO it would be very helpfull ). While refs are Objects, the main distinction is imutability. Also: - apps embeding or extending ant can fully customize _all_ aspects of property processing, including ${} replacement and even the syntax. - it should be very easy to hook a different storage mechanism ( i.e. integrated with the embeding app, without requiring copy of properties ). - it should be possible to avoid copy when creating execution frames ( by using a chain that keeps changes and delegates getters ). - dynamic properties support ( my original itch :-) Please wait few days before firing, it seems all tests are passing and gump works - but I'm sure there are few problems :-) ( I'll commit the change in Project later today ) PR: Obtained from: Submitted by: Reviewed by: git-svn-id: https://svn.apache.org/repos/asf/ant/core/trunk@273709 13f79535-47bb-0310-9956-ffa450edef68
23 years ago
123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315316317318319320321322323324325326327328329330331332333334335336337338339340341342343344345346347348349350351352353354355356357358359360361362363364365366367368369370371372373374375376377378379380381382383384385386387388389390391392393394395396397398399400401402403404405406407408409410411412413414415416417418419420421422423424425426427428429430431432433434435436437438439440441442443444445446447448449450451452453454455456457458459460461462463464465466467468469470471472473474475476477478479480481482483484485486487488489490491492493494495496497498499500501502503504505506507508509510511512513514515516517518519520521522523524525526527528529530531532533534535536537538539540541542543544545546547548549550551552553554555556557558559560561562563564565566567568569570571572573574575576577578579580581582583584585586587588589590591592593594595596597598599600601602603604605606607608609610611612613614615616617618619620621622623624625626627628629630631
  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.Hashtable;
  20. import java.util.Vector;
  21. import java.util.Enumeration;
  22. /* ISSUES:
  23. - ns param. It could be used to provide "namespaces" for properties, which
  24. may be more flexible.
  25. - Object value. In ant1.5 String is used for Properties - but it would be nice
  26. to support generic Objects (the property remains immutable - you can't change
  27. the associated object). This will also allow JSP-EL style setting using the
  28. Object if an attribute contains only the property (name="${property}" could
  29. avoid Object->String->Object conversion)
  30. - Currently we "chain" only for get and set property (probably most users
  31. will only need that - if they need more they can replace the top helper).
  32. Need to discuss this and find if we need more.
  33. */
  34. /** NOT FINAL. API MAY CHANGE
  35. *
  36. * Deals with properties - substitution, dynamic properties, etc.
  37. *
  38. * This is the same code as in Ant1.5. The main addition is the ability
  39. * to chain multiple PropertyHelpers and to replace the default.
  40. *
  41. * @since Ant 1.6
  42. */
  43. public class PropertyHelper {
  44. private Project project;
  45. private PropertyHelper next;
  46. /** Project properties map (usually String to String). */
  47. private Hashtable properties = new Hashtable();
  48. /**
  49. * Map of "user" properties (as created in the Ant task, for example).
  50. * Note that these key/value pairs are also always put into the
  51. * project properties, so only the project properties need to be queried.
  52. * Mapping is String to String.
  53. */
  54. private Hashtable userProperties = new Hashtable();
  55. /**
  56. * Map of inherited "user" properties - that are those "user"
  57. * properties that have been created by tasks and not been set
  58. * from the command line or a GUI tool.
  59. * Mapping is String to String.
  60. */
  61. private Hashtable inheritedProperties = new Hashtable();
  62. /**
  63. * Default constructor.
  64. */
  65. protected PropertyHelper() {
  66. }
  67. //override facility for subclasses to put custom hashtables in
  68. // -------------------- Hook management --------------------
  69. /**
  70. * Set the project for which this helper is performing property resolution
  71. *
  72. * @param p the project instance.
  73. */
  74. public void setProject(Project p) {
  75. this.project = p;
  76. }
  77. /** There are 2 ways to hook into property handling:
  78. * - you can replace the main PropertyHelper. The replacement is required
  79. * to support the same semantics (of course :-)
  80. *
  81. * - you can chain a property helper capable of storing some properties.
  82. * Again, you are required to respect the immutability semantics (at
  83. * least for non-dynamic properties)
  84. *
  85. * @param next the next property helper in the chain.
  86. */
  87. public void setNext(PropertyHelper next) {
  88. this.next = next;
  89. }
  90. /**
  91. * Get the next property helper in the chain.
  92. *
  93. * @return the next property helper.
  94. */
  95. public PropertyHelper getNext() {
  96. return next;
  97. }
  98. /**
  99. * Factory method to create a property processor.
  100. * Users can provide their own or replace it using "ant.PropertyHelper"
  101. * reference. User tasks can also add themselves to the chain, and provide
  102. * dynamic properties.
  103. *
  104. * @param project the project fro which the property helper is required.
  105. *
  106. * @return the project's property helper.
  107. */
  108. public static synchronized
  109. PropertyHelper getPropertyHelper(Project project) {
  110. PropertyHelper helper
  111. = (PropertyHelper) project.getReference(MagicNames.REFID_PROPERTY_HELPER);
  112. if (helper != null) {
  113. return helper;
  114. }
  115. helper = new PropertyHelper();
  116. helper.setProject(project);
  117. project.addReference(MagicNames.REFID_PROPERTY_HELPER, helper);
  118. return helper;
  119. }
  120. // -------------------- Methods to override --------------------
  121. /**
  122. * Sets a property. Any existing property of the same name
  123. * is overwritten, unless it is a user property. Will be called
  124. * from setProperty().
  125. *
  126. * If all helpers return false, the property will be saved in
  127. * the default properties table by setProperty.
  128. *
  129. * @param ns The namespace that the property is in (currently
  130. * not used.
  131. * @param name The name of property to set.
  132. * Must not be <code>null</code>.
  133. * @param value The new value of the property.
  134. * Must not be <code>null</code>.
  135. * @param inherited True if this property is inherited (an [sub]ant[call] property).
  136. * @param user True if this property is a user property.
  137. * @param isNew True is this is a new property.
  138. * @return true if this helper has stored the property, false if it
  139. * couldn't. Each helper should delegate to the next one (unless it
  140. * has a good reason not to).
  141. */
  142. public boolean setPropertyHook(String ns, String name,
  143. Object value,
  144. boolean inherited, boolean user,
  145. boolean isNew) {
  146. if (getNext() != null) {
  147. boolean subst = getNext().setPropertyHook(ns, name, value,
  148. inherited, user, isNew);
  149. // If next has handled the property
  150. if (subst) {
  151. return true;
  152. }
  153. }
  154. return false;
  155. }
  156. /** Get a property. If all hooks return null, the default
  157. * tables will be used.
  158. *
  159. * @param ns namespace of the sought property.
  160. * @param name name of the sought property.
  161. * @param user True if this is a user property.
  162. * @return The property, if returned by a hook, or null if none.
  163. */
  164. public Object getPropertyHook(String ns, String name, boolean user) {
  165. if (getNext() != null) {
  166. Object o = getNext().getPropertyHook(ns, name, user);
  167. if (o != null) {
  168. return o;
  169. }
  170. }
  171. // Experimental/Testing, will be removed
  172. if (name.startsWith("toString:")) {
  173. name = name.substring("toString:".length());
  174. Object v = project.getReference(name);
  175. return (v == null) ? null : v.toString();
  176. }
  177. return null;
  178. }
  179. // -------------------- Optional methods --------------------
  180. // You can override those methods if you want to optimize or
  181. // do advanced things (like support a special syntax).
  182. // The methods do not chain - you should use them when embedding ant
  183. // (by replacing the main helper)
  184. /**
  185. * Parses a string containing <code>${xxx}</code> style property
  186. * references into two lists. The first list is a collection
  187. * of text fragments, while the other is a set of string property names.
  188. * <code>null</code> entries in the first list indicate a property
  189. * reference from the second list.
  190. *
  191. * It can be overridden with a more efficient or customized version.
  192. *
  193. * @param value Text to parse. Must not be <code>null</code>.
  194. * @param fragments List to add text fragments to.
  195. * Must not be <code>null</code>.
  196. * @param propertyRefs List to add property names to.
  197. * Must not be <code>null</code>.
  198. *
  199. * @exception BuildException if the string contains an opening
  200. * <code>${</code> without a closing
  201. * <code>}</code>
  202. */
  203. public void parsePropertyString(String value, Vector fragments,
  204. Vector propertyRefs)
  205. throws BuildException {
  206. parsePropertyStringDefault(value, fragments, propertyRefs);
  207. }
  208. /**
  209. * Replaces <code>${xxx}</code> style constructions in the given value
  210. * with the string value of the corresponding data types.
  211. *
  212. * @param ns The namespace for the property.
  213. * @param value The string to be scanned for property references.
  214. * May be <code>null</code>, in which case this
  215. * method returns immediately with no effect.
  216. * @param keys Mapping (String to String) of property names to their
  217. * values. If <code>null</code>, only project properties will
  218. * be used.
  219. *
  220. * @exception BuildException if the string contains an opening
  221. * <code>${</code> without a closing
  222. * <code>}</code>
  223. * @return the original string with the properties replaced, or
  224. * <code>null</code> if the original string is <code>null</code>.
  225. */
  226. public String replaceProperties(String ns, String value, Hashtable keys)
  227. throws BuildException {
  228. if (value == null) {
  229. return null;
  230. }
  231. Vector fragments = new Vector();
  232. Vector propertyRefs = new Vector();
  233. parsePropertyString(value, fragments, propertyRefs);
  234. StringBuffer sb = new StringBuffer();
  235. Enumeration i = fragments.elements();
  236. Enumeration j = propertyRefs.elements();
  237. while (i.hasMoreElements()) {
  238. String fragment = (String) i.nextElement();
  239. if (fragment == null) {
  240. String propertyName = (String) j.nextElement();
  241. Object replacement = null;
  242. // try to get it from the project or keys
  243. // Backward compatibility
  244. if (keys != null) {
  245. replacement = keys.get(propertyName);
  246. }
  247. if (replacement == null) {
  248. replacement = getProperty(ns, propertyName);
  249. }
  250. if (replacement == null) {
  251. project.log("Property \"" + propertyName
  252. + "\" has not been set", Project.MSG_VERBOSE);
  253. }
  254. fragment = (replacement != null)
  255. ? replacement.toString()
  256. : "${" + propertyName + "}";
  257. }
  258. sb.append(fragment);
  259. }
  260. return sb.toString();
  261. }
  262. // -------------------- Default implementation --------------------
  263. // Methods used to support the default behavior and provide backward
  264. // compatibility. Some will be deprecated, you should avoid calling them.
  265. /** Default implementation of setProperty. Will be called from Project.
  266. * This is the original 1.5 implementation, with calls to the hook
  267. * added.
  268. * @param ns The namespace for the property (currently not used).
  269. * @param name The name of the property.
  270. * @param value The value to set the property to.
  271. * @param verbose If this is true output extra log messages.
  272. * @return true if the property is set.
  273. */
  274. public synchronized boolean setProperty(String ns, String name,
  275. Object value, boolean verbose) {
  276. // user (CLI) properties take precedence
  277. if (null != userProperties.get(name)) {
  278. if (verbose) {
  279. project.log("Override ignored for user property \"" + name
  280. + "\"", Project.MSG_VERBOSE);
  281. }
  282. return false;
  283. }
  284. boolean done = setPropertyHook(ns, name, value, false, false, false);
  285. if (done) {
  286. return true;
  287. }
  288. if (null != properties.get(name) && verbose) {
  289. project.log("Overriding previous definition of property \"" + name
  290. + "\"", Project.MSG_VERBOSE);
  291. }
  292. if (verbose) {
  293. project.log("Setting project property: " + name + " -> "
  294. + value, Project.MSG_DEBUG);
  295. }
  296. properties.put(name, value);
  297. return true;
  298. }
  299. /**
  300. * Sets a property if no value currently exists. If the property
  301. * exists already, a message is logged and the method returns with
  302. * no other effect.
  303. *
  304. * @param ns The namespace for the property (currently not used).
  305. * @param name The name of property to set.
  306. * Must not be <code>null</code>.
  307. * @param value The new value of the property.
  308. * Must not be <code>null</code>.
  309. * @since Ant 1.6
  310. */
  311. public synchronized void setNewProperty(String ns, String name,
  312. Object value) {
  313. if (null != properties.get(name)) {
  314. project.log("Override ignored for property \"" + name
  315. + "\"", Project.MSG_VERBOSE);
  316. return;
  317. }
  318. boolean done = setPropertyHook(ns, name, value, false, false, true);
  319. if (done) {
  320. return;
  321. }
  322. project.log("Setting project property: " + name + " -> "
  323. + value, Project.MSG_DEBUG);
  324. if (name != null && value != null) {
  325. properties.put(name, value);
  326. }
  327. }
  328. /**
  329. * Sets a user property, which cannot be overwritten by
  330. * set/unset property calls. Any previous value is overwritten.
  331. * @param ns The namespace for the property (currently not used).
  332. * @param name The name of property to set.
  333. * Must not be <code>null</code>.
  334. * @param value The new value of the property.
  335. * Must not be <code>null</code>.
  336. */
  337. public synchronized void setUserProperty(String ns, String name,
  338. Object value) {
  339. project.log("Setting ro project property: " + name + " -> "
  340. + value, Project.MSG_DEBUG);
  341. userProperties.put(name, value);
  342. boolean done = setPropertyHook(ns, name, value, false, true, false);
  343. if (done) {
  344. return;
  345. }
  346. properties.put(name, value);
  347. }
  348. /**
  349. * Sets an inherited user property, which cannot be overwritten by set/unset
  350. * property calls. Any previous value is overwritten. Also marks
  351. * these properties as properties that have not come from the
  352. * command line.
  353. *
  354. * @param ns The namespace for the property (currently not used).
  355. * @param name The name of property to set.
  356. * Must not be <code>null</code>.
  357. * @param value The new value of the property.
  358. * Must not be <code>null</code>.
  359. */
  360. public synchronized void setInheritedProperty(String ns, String name,
  361. Object value) {
  362. inheritedProperties.put(name, value);
  363. project.log("Setting ro project property: " + name + " -> "
  364. + value, Project.MSG_DEBUG);
  365. userProperties.put(name, value);
  366. boolean done = setPropertyHook(ns, name, value, true, false, false);
  367. if (done) {
  368. return;
  369. }
  370. properties.put(name, value);
  371. }
  372. // -------------------- Getting properties --------------------
  373. /**
  374. * Returns the value of a property, if it is set. You can override
  375. * this method in order to plug your own storage.
  376. *
  377. * @param ns The namespace for the property (currently not used).
  378. * @param name The name of the property.
  379. * May be <code>null</code>, in which case
  380. * the return value is also <code>null</code>.
  381. * @return the property value, or <code>null</code> for no match
  382. * or if a <code>null</code> name is provided.
  383. */
  384. public synchronized Object getProperty(String ns, String name) {
  385. if (name == null) {
  386. return null;
  387. }
  388. Object o = getPropertyHook(ns, name, false);
  389. if (o != null) {
  390. return o;
  391. }
  392. return properties.get(name);
  393. }
  394. /**
  395. * Returns the value of a user property, if it is set.
  396. *
  397. * @param ns The namespace for the property (currently not used).
  398. * @param name The name of the property.
  399. * May be <code>null</code>, in which case
  400. * the return value is also <code>null</code>.
  401. * @return the property value, or <code>null</code> for no match
  402. * or if a <code>null</code> name is provided.
  403. */
  404. public synchronized Object getUserProperty(String ns, String name) {
  405. if (name == null) {
  406. return null;
  407. }
  408. Object o = getPropertyHook(ns, name, true);
  409. if (o != null) {
  410. return o;
  411. }
  412. return userProperties.get(name);
  413. }
  414. // -------------------- Access to property tables --------------------
  415. // This is used to support ant call and similar tasks. It should be
  416. // deprecated, it is possible to use a better (more efficient)
  417. // mechanism to preserve the context.
  418. // TODO: do we need to delegate ?
  419. /**
  420. * Returns a copy of the properties table.
  421. * @return a hashtable containing all properties
  422. * (including user properties).
  423. */
  424. public Hashtable getProperties() {
  425. return new Hashtable(properties);
  426. // There is a better way to save the context. This shouldn't
  427. // delegate to next, it's for backward compatibility only.
  428. }
  429. /**
  430. * Returns a copy of the user property hashtable
  431. * @return a hashtable containing just the user properties
  432. */
  433. public Hashtable getUserProperties() {
  434. return new Hashtable(userProperties);
  435. }
  436. /**
  437. * special back door for subclasses, internal access to
  438. * the hashtables
  439. * @return the live hashtable of all properties
  440. */
  441. protected Hashtable getInternalProperties() {
  442. return properties;
  443. }
  444. /**
  445. * special back door for subclasses, internal access to
  446. * the hashtables
  447. *
  448. * @return the live hashtable of user properties
  449. */
  450. protected Hashtable getInternalUserProperties() {
  451. return userProperties;
  452. }
  453. /**
  454. * special back door for subclasses, internal access to
  455. * the hashtables
  456. *
  457. * @return the live hashtable inherited properties
  458. */
  459. protected Hashtable getInternalInheritedProperties() {
  460. return inheritedProperties;
  461. }
  462. /**
  463. * Copies all user properties that have not been set on the
  464. * command line or a GUI tool from this instance to the Project
  465. * instance given as the argument.
  466. *
  467. * <p>To copy all "user" properties, you will also have to call
  468. * {@link #copyUserProperties copyUserProperties}.</p>
  469. *
  470. * @param other the project to copy the properties to. Must not be null.
  471. *
  472. * @since Ant 1.6
  473. */
  474. public void copyInheritedProperties(Project other) {
  475. Enumeration e = inheritedProperties.keys();
  476. while (e.hasMoreElements()) {
  477. String arg = e.nextElement().toString();
  478. if (other.getUserProperty(arg) != null) {
  479. continue;
  480. }
  481. Object value = inheritedProperties.get(arg);
  482. other.setInheritedProperty(arg, value.toString());
  483. }
  484. }
  485. /**
  486. * Copies all user properties that have been set on the command
  487. * line or a GUI tool from this instance to the Project instance
  488. * given as the argument.
  489. *
  490. * <p>To copy all "user" properties, you will also have to call
  491. * {@link #copyInheritedProperties copyInheritedProperties}.</p>
  492. *
  493. * @param other the project to copy the properties to. Must not be null.
  494. *
  495. * @since Ant 1.6
  496. */
  497. public void copyUserProperties(Project other) {
  498. Enumeration e = userProperties.keys();
  499. while (e.hasMoreElements()) {
  500. Object arg = e.nextElement();
  501. if (inheritedProperties.containsKey(arg)) {
  502. continue;
  503. }
  504. Object value = userProperties.get(arg);
  505. other.setUserProperty(arg.toString(), value.toString());
  506. }
  507. }
  508. // -------------------- Property parsing --------------------
  509. // Moved from ProjectHelper. You can override the static method -
  510. // this is used for backward compatibility (for code that calls
  511. // the parse method in ProjectHelper).
  512. /** Default parsing method. It is here only to support backward compatibility
  513. * for the static ProjectHelper.parsePropertyString().
  514. */
  515. static void parsePropertyStringDefault(String value, Vector fragments,
  516. Vector propertyRefs)
  517. throws BuildException {
  518. int prev = 0;
  519. int pos;
  520. //search for the next instance of $ from the 'prev' position
  521. while ((pos = value.indexOf("$", prev)) >= 0) {
  522. //if there was any text before this, add it as a fragment
  523. //TODO, this check could be modified to go if pos>prev;
  524. //seems like this current version could stick empty strings
  525. //into the list
  526. if (pos > 0) {
  527. fragments.addElement(value.substring(prev, pos));
  528. }
  529. //if we are at the end of the string, we tack on a $
  530. //then move past it
  531. if (pos == (value.length() - 1)) {
  532. fragments.addElement("$");
  533. prev = pos + 1;
  534. } else if (value.charAt(pos + 1) != '{') {
  535. //peek ahead to see if the next char is a property or not
  536. //not a property: insert the char as a literal
  537. /*
  538. fragments.addElement(value.substring(pos + 1, pos + 2));
  539. prev = pos + 2;
  540. */
  541. if (value.charAt(pos + 1) == '$') {
  542. //backwards compatibility two $ map to one mode
  543. fragments.addElement("$");
  544. prev = pos + 2;
  545. } else {
  546. //new behaviour: $X maps to $X for all values of X!='$'
  547. fragments.addElement(value.substring(pos, pos + 2));
  548. prev = pos + 2;
  549. }
  550. } else {
  551. //property found, extract its name or bail on a typo
  552. int endName = value.indexOf('}', pos);
  553. if (endName < 0) {
  554. throw new BuildException("Syntax error in property: "
  555. + value);
  556. }
  557. String propertyName = value.substring(pos + 2, endName);
  558. fragments.addElement(null);
  559. propertyRefs.addElement(propertyName);
  560. prev = endName + 1;
  561. }
  562. }
  563. //no more $ signs found
  564. //if there is any tail to the file, append it
  565. if (prev < value.length()) {
  566. fragments.addElement(value.substring(prev));
  567. }
  568. }
  569. }