Emmanuel FELLER wrote:
Hi Steve,
Thanks for your response.
I tried your way yesterday evening but now I have 18 properties files (16 with business and build properties and 2 for the paths to the properties file). Some of them have 50-60 properties defined, and all others have only 3 or 4.
that seems a reasonable number. If you have one per target system and one per app server then you avoid an explosive n*m growth in configs. So you keep scalability manageable.
Is that better than having recursive resolution ? That's why I asked my question : what is the limit betwenn several properties to maintain and the recurive resolution concern ?
In our mind (my boss and me), we won't be able to maintain this lot of properties files. (Because now we should store them into a SCM and control the dependancies and the coherence betwenn all properties file for a build as we could have multiple build in the same hour with "naturely" change of properties).
Then you need to run ant with a command line that is ant -Dbuild.target=chamonix, or ant -Dbuild.target=zermatt for the different systems.
So we will develope a recursive resolution task, it solve the potential issue on multiple properties files management.
I will contribute this if your are interested.
I am afraid, for the same reason we arent going to put the ant-contrib one in: it is the wrong way to do things.
If it were done, then it is better done properly. Recursive expansion is a hack...normal languages use arrays and maps to do this kind of thing.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
