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
123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315316317318319320321322323324325326327328329330331332333334335336337338339340341342343344345346347348349350351352353354355356357358359360361362363364365366367368369370371372373374375376377378379380381382383384385386387388389390391392393394395396397398399400401402403404405406407408409410411412413414415416417418419420421422423424425426427428429430431432433434435436437438439440441442443444445446447448449450451452453454455456457458459460461462463464465466467468469470471472473474475476477478479480481482483484485486487488489490491492493494495496497498499500501502503504505506507508509510511512513514515516517518519520521522523524525526527528529530531532533534535536537538539540541542543544545546547548549550551552553554555556557558559560561562563564565566567568569570571572573574575576577578579580581582583584585586587588589590591592593594595596597598599600601602603604605606607608609610611612613614615616617618619620621622623624625626627628629630631632633634635636637638639640641642643644645646
  1. /*
  2. * The Apache Software License, Version 1.1
  3. *
  4. * Copyright (c) 2002-2003 The Apache Software Foundation. All rights
  5. * reserved.
  6. *
  7. * Redistribution and use in source and binary forms, with or without
  8. * modification, are permitted provided that the following conditions
  9. * are met:
  10. *
  11. * 1. Redistributions of source code must retain the above copyright
  12. * notice, this list of conditions and the following disclaimer.
  13. *
  14. * 2. Redistributions in binary form must reproduce the above copyright
  15. * notice, this list of conditions and the following disclaimer in
  16. * the documentation and/or other materials provided with the
  17. * distribution.
  18. *
  19. * 3. The end-user documentation included with the redistribution, if
  20. * any, must include the following acknowlegement:
  21. * "This product includes software developed by the
  22. * Apache Software Foundation (http://www.apache.org/)."
  23. * Alternately, this acknowlegement may appear in the software itself,
  24. * if and wherever such third-party acknowlegements normally appear.
  25. *
  26. * 4. The names "Ant" and "Apache Software
  27. * Foundation" must not be used to endorse or promote products derived
  28. * from this software without prior written permission. For written
  29. * permission, please contact apache@apache.org.
  30. *
  31. * 5. Products derived from this software may not be called "Apache"
  32. * nor may "Apache" appear in their names without prior written
  33. * permission of the Apache Group.
  34. *
  35. * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED
  36. * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
  37. * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
  38. * DISCLAIMED. IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR
  39. * ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
  40. * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
  41. * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
  42. * USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
  43. * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
  44. * OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
  45. * OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
  46. * SUCH DAMAGE.
  47. * ====================================================================
  48. *
  49. * This software consists of voluntary contributions made by many
  50. * individuals on behalf of the Apache Software Foundation. For more
  51. * information on the Apache Software Foundation, please see
  52. * <http://www.apache.org/>.
  53. */
  54. package org.apache.tools.ant;
  55. import java.util.Hashtable;
  56. import java.util.Vector;
  57. import java.util.Enumeration;
  58. /* ISSUES:
  59. - ns param. It could be used to provide "namespaces" for properties, which
  60. may be more flexible.
  61. - Object value. In ant1.5 String is used for Properties - but it would be nice
  62. to support generic Objects (the property remains immutable - you can't change
  63. the associated object). This will also allow JSP-EL style setting using the
  64. Object if an attribute contains only the property (name="${property}" could
  65. avoid Object->String->Object conversion)
  66. - Currently we "chain" only for get and set property (probably most users
  67. will only need that - if they need more they can replace the top helper).
  68. Need to discuss this and find if we need more.
  69. */
  70. /** NOT FINAL. API MAY CHANGE
  71. *
  72. * Deals with properties - substitution, dynamic properties, etc.
  73. *
  74. * This is the same code as in Ant1.5. The main addition is the ability
  75. * to chain multiple PropertyHelpers and to replace the default.
  76. *
  77. * @since Ant 1.6
  78. * @author Costin Manolache
  79. */
  80. public class PropertyHelper {
  81. private Project project;
  82. private PropertyHelper next;
  83. /** Project properties map (usually String to String). */
  84. private Hashtable properties = new Hashtable();
  85. /**
  86. * Map of "user" properties (as created in the Ant task, for example).
  87. * Note that these key/value pairs are also always put into the
  88. * project properties, so only the project properties need to be queried.
  89. * Mapping is String to String.
  90. */
  91. private Hashtable userProperties = new Hashtable();
  92. /**
  93. * Map of inherited "user" properties - that are those "user"
  94. * properties that have been created by tasks and not been set
  95. * from the command line or a GUI tool.
  96. * Mapping is String to String.
  97. */
  98. private Hashtable inheritedProperties = new Hashtable();
  99. /**
  100. * Default constructor.
  101. */
  102. protected PropertyHelper() {
  103. }
  104. // -------------------- Hook management --------------------
  105. /**
  106. * Set the project for which this helper is performing property resolution
  107. *
  108. * @param p the project instance.
  109. */
  110. public void setProject(Project p) {
  111. this.project = p;
  112. }
  113. /** There are 2 ways to hook into property handling:
  114. * - you can replace the main PropertyHelper. The replacement is required
  115. * to support the same semantics (of course :-)
  116. *
  117. * - you can chain a property helper capable of storing some properties.
  118. * Again, you are required to respect the immutability semantics (at
  119. * least for non-dynamic properties)
  120. *
  121. * @param next the next property helper in the chain.
  122. */
  123. public void setNext(PropertyHelper next) {
  124. this.next = next;
  125. }
  126. /**
  127. * Get the next property helper in the chain.
  128. *
  129. * @return the next property helper.
  130. */
  131. public PropertyHelper getNext() {
  132. return next;
  133. }
  134. /**
  135. * Factory method to create a property processor.
  136. * Users can provide their own or replace it using "ant.PropertyHelper"
  137. * reference. User tasks can also add themselves to the chain, and provide
  138. * dynamic properties.
  139. *
  140. * @param project the project fro which the property helper is required.
  141. *
  142. * @return the project's property helper.
  143. */
  144. public static synchronized
  145. PropertyHelper getPropertyHelper(Project project) {
  146. PropertyHelper helper
  147. = (PropertyHelper) project.getReference("ant.PropertyHelper");
  148. if (helper != null) {
  149. return helper;
  150. }
  151. helper = new PropertyHelper();
  152. helper.setProject(project);
  153. project.addReference("ant.PropertyHelper", helper);
  154. return helper;
  155. }
  156. // -------------------- Methods to override --------------------
  157. /**
  158. * Sets a property. Any existing property of the same name
  159. * is overwritten, unless it is a user property. Will be called
  160. * from setProperty().
  161. *
  162. * If all helpers return false, the property will be saved in
  163. * the default properties table by setProperty.
  164. *
  165. * @param name The name of property to set.
  166. * Must not be <code>null</code>.
  167. * @param value The new value of the property.
  168. * Must not be <code>null</code>.
  169. * @return true if this helper has stored the property, false if it
  170. * couldn't. Each helper should delegate to the next one (unless it
  171. * has a good reason not to).
  172. */
  173. public boolean setPropertyHook(String ns, String name,
  174. Object value,
  175. boolean inherited, boolean user,
  176. boolean isNew) {
  177. if (getNext() != null) {
  178. boolean subst = getNext().setPropertyHook(ns, name, value,
  179. inherited, user, isNew);
  180. // If next has handled the property
  181. if (subst) {
  182. return true;
  183. }
  184. }
  185. return false;
  186. }
  187. /** Get a property. If all hooks return null, the default
  188. * tables will be used.
  189. *
  190. * @param ns
  191. * @param name
  192. * @return
  193. */
  194. public Object getPropertyHook(String ns, String name, boolean user) {
  195. if (getNext() != null) {
  196. Object o = getNext().getPropertyHook(ns, name, user);
  197. if (o != null) {
  198. return o;
  199. }
  200. }
  201. // Experimental/Testing, will be removed
  202. if (name.startsWith("toString:")) {
  203. name = name.substring("toString:".length());
  204. Object v = project.getReference(name);
  205. if (v == null) {
  206. return null;
  207. }
  208. return v.toString();
  209. }
  210. return null;
  211. }
  212. // -------------------- Optional methods --------------------
  213. // You can override those methods if you want to optimize or
  214. // do advanced things (like support a special syntax).
  215. // The methods do not chain - you should use them when embedding ant
  216. // (by replacing the main helper)
  217. /**
  218. * Parses a string containing <code>${xxx}</code> style property
  219. * references into two lists. The first list is a collection
  220. * of text fragments, while the other is a set of string property names.
  221. * <code>null</code> entries in the first list indicate a property
  222. * reference from the second list.
  223. *
  224. * It can be overridden with a more efficient or customized version.
  225. *
  226. * @param value Text to parse. Must not be <code>null</code>.
  227. * @param fragments List to add text fragments to.
  228. * Must not be <code>null</code>.
  229. * @param propertyRefs List to add property names to.
  230. * Must not be <code>null</code>.
  231. *
  232. * @exception BuildException if the string contains an opening
  233. * <code>${</code> without a closing
  234. * <code>}</code>
  235. */
  236. public void parsePropertyString(String value, Vector fragments,
  237. Vector propertyRefs)
  238. throws BuildException {
  239. parsePropertyStringDefault(value, fragments, propertyRefs);
  240. }
  241. /**
  242. * Replaces <code>${xxx}</code> style constructions in the given value
  243. * with the string value of the corresponding data types.
  244. *
  245. * @param value The string to be scanned for property references.
  246. * May be <code>null</code>, in which case this
  247. * method returns immediately with no effect.
  248. * @param keys Mapping (String to String) of property names to their
  249. * values. If <code>null</code>, only project properties will
  250. * be used.
  251. *
  252. * @exception BuildException if the string contains an opening
  253. * <code>${</code> without a closing
  254. * <code>}</code>
  255. * @return the original string with the properties replaced, or
  256. * <code>null</code> if the original string is <code>null</code>.
  257. */
  258. public String replaceProperties(String ns, String value,
  259. Hashtable keys)
  260. throws BuildException {
  261. if (value == null) {
  262. return null;
  263. }
  264. Vector fragments = new Vector();
  265. Vector propertyRefs = new Vector();
  266. parsePropertyString(value, fragments, propertyRefs);
  267. StringBuffer sb = new StringBuffer();
  268. Enumeration i = fragments.elements();
  269. Enumeration j = propertyRefs.elements();
  270. while (i.hasMoreElements()) {
  271. String fragment = (String) i.nextElement();
  272. if (fragment == null) {
  273. String propertyName = (String) j.nextElement();
  274. Object replacement = null;
  275. // try to get it from the project or keys
  276. // Backward compatibility
  277. if (keys != null) {
  278. replacement = keys.get(propertyName);
  279. }
  280. if (replacement == null) {
  281. replacement = getProperty(ns, propertyName);
  282. }
  283. if (replacement == null) {
  284. project.log("Property ${" + propertyName
  285. + "} has not been set", Project.MSG_VERBOSE);
  286. }
  287. fragment = (replacement != null)
  288. ? replacement.toString()
  289. : "${" + propertyName + "}";
  290. }
  291. sb.append(fragment);
  292. }
  293. return sb.toString();
  294. }
  295. // -------------------- Default implementation --------------------
  296. // Methods used to support the default behavior and provide backward
  297. // compatibility. Some will be deprecated, you should avoid calling them.
  298. /** Default implementation of setProperty. Will be called from Project.
  299. * This is the original 1.5 implementation, with calls to the hook
  300. * added.
  301. */
  302. public synchronized boolean setProperty(String ns, String name,
  303. Object value, boolean verbose) {
  304. // user (CLI) properties take precedence
  305. if (null != userProperties.get(name)) {
  306. if (verbose) {
  307. project.log("Override ignored for user property " + name,
  308. Project.MSG_VERBOSE);
  309. }
  310. return false;
  311. }
  312. boolean done = setPropertyHook(ns, name, value, false, false, false);
  313. if (done) {
  314. return true;
  315. }
  316. if (null != properties.get(name) && verbose) {
  317. project.log("Overriding previous definition of property " + name,
  318. Project.MSG_VERBOSE);
  319. }
  320. if (verbose) {
  321. project.log("Setting project property: " + name + " -> "
  322. + value, Project.MSG_DEBUG);
  323. }
  324. properties.put(name, value);
  325. return true;
  326. }
  327. /**
  328. * Sets a property if no value currently exists. If the property
  329. * exists already, a message is logged and the method returns with
  330. * no other effect.
  331. *
  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. * @since Ant 1.6
  337. */
  338. public synchronized void setNewProperty(String ns, String name,
  339. Object value) {
  340. if (null != properties.get(name)) {
  341. project.log("Override ignored for property " + name,
  342. Project.MSG_VERBOSE);
  343. return;
  344. }
  345. boolean done = setPropertyHook(ns, name, value, false, false, true);
  346. if (done) {
  347. return;
  348. }
  349. project.log("Setting project property: " + name + " -> "
  350. + value, Project.MSG_DEBUG);
  351. if (name != null && value != null) {
  352. properties.put(name, value);
  353. }
  354. }
  355. /**
  356. * Sets a user property, which cannot be overwritten by
  357. * set/unset property calls. Any previous value is overwritten.
  358. * @param name The name of property to set.
  359. * Must not be <code>null</code>.
  360. * @param value The new value of the property.
  361. * Must not be <code>null</code>.
  362. */
  363. public synchronized void setUserProperty(String ns, String name,
  364. Object value) {
  365. project.log("Setting ro project property: " + name + " -> "
  366. + value, Project.MSG_DEBUG);
  367. userProperties.put(name, value);
  368. boolean done = setPropertyHook(ns, name, value, false, true, false);
  369. if (done) {
  370. return;
  371. }
  372. properties.put(name, value);
  373. }
  374. /**
  375. * Sets a user property, which cannot be overwritten by set/unset
  376. * property calls. Any previous value is overwritten. Also marks
  377. * these properties as properties that have not come from the
  378. * command line.
  379. *
  380. * @param name The name of property to set.
  381. * Must not be <code>null</code>.
  382. * @param value The new value of the property.
  383. * Must not be <code>null</code>.
  384. */
  385. public synchronized void setInheritedProperty(String ns, String name,
  386. Object value) {
  387. inheritedProperties.put(name, value);
  388. project.log("Setting ro project property: " + name + " -> "
  389. + value, Project.MSG_DEBUG);
  390. userProperties.put(name, value);
  391. boolean done = setPropertyHook(ns, name, value, true, false, false);
  392. if (done) {
  393. return;
  394. }
  395. properties.put(name, value);
  396. }
  397. // -------------------- Getting properties --------------------
  398. /**
  399. * Returns the value of a property, if it is set. You can override
  400. * this method in order to plug your own storage.
  401. *
  402. * @param name The name of the property.
  403. * May be <code>null</code>, in which case
  404. * the return value is also <code>null</code>.
  405. * @return the property value, or <code>null</code> for no match
  406. * or if a <code>null</code> name is provided.
  407. */
  408. public synchronized Object getProperty(String ns, String name) {
  409. if (name == null) {
  410. return null;
  411. }
  412. Object o = getPropertyHook(ns, name, false);
  413. if (o != null) {
  414. return o;
  415. }
  416. return properties.get(name);
  417. }
  418. /**
  419. * Returns the value of a user property, if it is set.
  420. *
  421. * @param name The name of the property.
  422. * May be <code>null</code>, in which case
  423. * the return value is also <code>null</code>.
  424. * @return the property value, or <code>null</code> for no match
  425. * or if a <code>null</code> name is provided.
  426. */
  427. public synchronized Object getUserProperty(String ns, String name) {
  428. if (name == null) {
  429. return null;
  430. }
  431. Object o = getPropertyHook(ns, name, true);
  432. if (o != null) {
  433. return o;
  434. }
  435. return userProperties.get(name);
  436. }
  437. // -------------------- Access to property tables --------------------
  438. // This is used to support ant call and similar tasks. It should be
  439. // deprecated, it is possible to use a better (more efficient)
  440. // mechanism to preserve the context.
  441. // TODO: do we need to delegate ?
  442. /**
  443. * Returns a copy of the properties table.
  444. * @return a hashtable containing all properties
  445. * (including user properties).
  446. */
  447. public Hashtable getProperties() {
  448. Hashtable propertiesCopy = new Hashtable();
  449. Enumeration e = properties.keys();
  450. while (e.hasMoreElements()) {
  451. Object name = e.nextElement();
  452. Object value = properties.get(name);
  453. propertiesCopy.put(name, value);
  454. }
  455. // There is a better way to save the context. This shouldn't
  456. // delegate to next, it's for backward compatibility only.
  457. return propertiesCopy;
  458. }
  459. /**
  460. * Returns a copy of the user property hashtable
  461. * @return a hashtable containing just the user properties
  462. */
  463. public Hashtable getUserProperties() {
  464. Hashtable propertiesCopy = new Hashtable();
  465. Enumeration e = userProperties.keys();
  466. while (e.hasMoreElements()) {
  467. Object name = e.nextElement();
  468. Object value = properties.get(name);
  469. propertiesCopy.put(name, value);
  470. }
  471. return propertiesCopy;
  472. }
  473. /**
  474. * Copies all user properties that have not been set on the
  475. * command line or a GUI tool from this instance to the Project
  476. * instance given as the argument.
  477. *
  478. * <p>To copy all "user" properties, you will also have to call
  479. * {@link #copyUserProperties copyUserProperties}.</p>
  480. *
  481. * @param other the project to copy the properties to. Must not be null.
  482. *
  483. * @since Ant 1.6
  484. */
  485. public void copyInheritedProperties(Project other) {
  486. Enumeration e = inheritedProperties.keys();
  487. while (e.hasMoreElements()) {
  488. String arg = e.nextElement().toString();
  489. if (other.getUserProperty(arg) != null) {
  490. continue;
  491. }
  492. Object value = inheritedProperties.get(arg);
  493. other.setInheritedProperty(arg, value.toString());
  494. }
  495. }
  496. /**
  497. * Copies all user properties that have been set on the command
  498. * line or a GUI tool from this instance to the Project instance
  499. * given as the argument.
  500. *
  501. * <p>To copy all "user" properties, you will also have to call
  502. * {@link #copyInheritedProperties copyInheritedProperties}.</p>
  503. *
  504. * @param other the project to copy the properties to. Must not be null.
  505. *
  506. * @since Ant 1.6
  507. */
  508. public void copyUserProperties(Project other) {
  509. Enumeration e = userProperties.keys();
  510. while (e.hasMoreElements()) {
  511. Object arg = e.nextElement();
  512. if (inheritedProperties.containsKey(arg)) {
  513. continue;
  514. }
  515. Object value = userProperties.get(arg);
  516. other.setUserProperty(arg.toString(), value.toString());
  517. }
  518. }
  519. // -------------------- Property parsing --------------------
  520. // Moved from ProjectHelper. You can override the static method -
  521. // this is used for backward compatibility (for code that calls
  522. // the parse method in ProjectHelper).
  523. /** Default parsing method. It is here only to support backward compatibility
  524. * for the static ProjectHelper.parsePropertyString().
  525. */
  526. static void parsePropertyStringDefault(String value, Vector fragments,
  527. Vector propertyRefs)
  528. throws BuildException {
  529. int prev = 0;
  530. int pos;
  531. //search for the next instance of $ from the 'prev' position
  532. while ((pos = value.indexOf("$", prev)) >= 0) {
  533. //if there was any text before this, add it as a fragment
  534. //TODO, this check could be modified to go if pos>prev;
  535. //seems like this current version could stick empty strings
  536. //into the list
  537. if (pos > 0) {
  538. fragments.addElement(value.substring(prev, pos));
  539. }
  540. //if we are at the end of the string, we tack on a $
  541. //then move past it
  542. if (pos == (value.length() - 1)) {
  543. fragments.addElement("$");
  544. prev = pos + 1;
  545. } else if (value.charAt(pos + 1) != '{') {
  546. //peek ahead to see if the next char is a property or not
  547. //not a property: insert the char as a literal
  548. /*
  549. fragments.addElement(value.substring(pos + 1, pos + 2));
  550. prev = pos + 2;
  551. */
  552. if (value.charAt(pos + 1) == '$') {
  553. //backwards compatibility two $ map to one mode
  554. fragments.addElement("$");
  555. prev = pos + 2;
  556. } else {
  557. //new behaviour: $X maps to $X for all values of X!='$'
  558. fragments.addElement(value.substring(pos, pos + 2));
  559. prev = pos + 2;
  560. }
  561. } else {
  562. //property found, extract its name or bail on a typo
  563. int endName = value.indexOf('}', pos);
  564. if (endName < 0) {
  565. throw new BuildException("Syntax error in property: "
  566. + value);
  567. }
  568. String propertyName = value.substring(pos + 2, endName);
  569. fragments.addElement(null);
  570. propertyRefs.addElement(propertyName);
  571. prev = endName + 1;
  572. }
  573. }
  574. //no more $ signs found
  575. //if there is any tail to the file, append it
  576. if (prev < value.length()) {
  577. fragments.addElement(value.substring(prev));
  578. }
  579. }
  580. }