Recursive properties resolution ?

[Emmanuel FELLER <Em...@maaf.fr>]

Hi,

I read the archive about the recursive properties and I am not convinced
so i would like to reopen the debate. (Or i may have missed the good
mail, if so correct me).

Excuse the long mail, but i prefer explain all my problem.

I do the all J2EE project build of my firm, the build process is exactly
the same for all the 8 projects on the 3 environnements (execpt
properties). So I did build files that accept param and all the param
are given in a properties file.

Now the dev are finishing and we will include some new environnement
like pre-production, production, debugging.

We cannot stay any more with one properties file for 1(project/env). We
had 24 properties file, now we will have more than 50 (and new projects
are comming).

Some properties are project and environnement independant, others are
project dependant, others are environnement dependant, others are both
project and environnement dependant.

So if i keep multiple file (one per project/env couple), i have multiple
and cross redundancy. And i have no way to define the env properties,
after the project properties and after project/env properties as they
are mixed and cross defined. (i tried without succes).

In this case I do not see what I can do to solve this without recursive
properties resolution.

What do you mind ? Should I develope with for an ant-contrib task as you
reject this for ant2
(http://jakarta.apache.org/ant/ant2/requested-features.html) ?

Emmanuel


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org

Re: RE : Recursive properties resolution ?

[Steve Loughran <st...@iseran.com>]

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: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org

RE : Recursive properties resolution ?

[Emmanuel FELLER <Em...@maaf.fr>]

>-----Message d'origine-----
>De : Steve Loughran [mailto:steve_l@iseran.com] 
>Envoyé : mardi 12 août 2003 18:37
>À : Ant Developers List
>Objet : Re: Recursive properties resolution ?
[snip/]
>> So if i keep multiple file (one per project/env couple), i 
>have multiple
>> and cross redundancy. And i have no way to define the env properties,
>> after the project properties and after project/env properties as they
>> are mixed and cross defined. (i tried without succes).
>> 
>> In this case I do not see what I can do to solve this 
>without recursive
>> properties resolution.
>
>-have multiple properties files...one per deployment target, one per 
>project, one per local installation.
>
>-use property expansion to decide which properties files to load
>
>e.g. a system would have
>
>system.properties:
>deploy.target=chamonix
>
>chamonix:properties
>deploy.platform=jboss
>deploy.process=ftp
>
[snip/]
><property file="build.properties/>
><property enviroment="env" />
><property file="system.properties/>
>
>   //loads chamonix.properties
><property file="${deploy.target}.properties/>
>//then app server specific stuff
><property file="${deploy.platform}.properties/>
>
[snip/]
>
>This gives you: dynamic configuration, and property file control. One 
>propfile/build file per app server platform, one per system with sys 
>config details, one per user with user options.
>

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.

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).
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.

Emmanuel


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org

Re: Recursive properties resolution ?

[Steve Loughran <st...@iseran.com>]

Emmanuel FELLER wrote:
> Hi,
> 
> I read the archive about the recursive properties and I am not convinced
> so i would like to reopen the debate. (Or i may have missed the good
> mail, if so correct me).
> 
> Excuse the long mail, but i prefer explain all my problem.
> 
> I do the all J2EE project build of my firm, the build process is exactly
> the same for all the 8 projects on the 3 environnements (execpt
> properties). So I did build files that accept param and all the param
> are given in a properties file.
> 
> Now the dev are finishing and we will include some new environnement
> like pre-production, production, debugging.
> 
> We cannot stay any more with one properties file for 1(project/env). We
> had 24 properties file, now we will have more than 50 (and new projects
> are comming).
> 
> Some properties are project and environnement independant, others are
> project dependant, others are environnement dependant, others are both
> project and environnement dependant.
> 
> So if i keep multiple file (one per project/env couple), i have multiple
> and cross redundancy. And i have no way to define the env properties,
> after the project properties and after project/env properties as they
> are mixed and cross defined. (i tried without succes).
> 
> In this case I do not see what I can do to solve this without recursive
> properties resolution.

-have multiple properties files...one per deployment target, one per 
project, one per local installation.

-use property expansion to decide which properties files to load

e.g. a system would have

system.properties:
deploy.target=chamonix

chamonix:properties
deploy.platform=jboss
deploy.process=ftp


jboss.properties:
install.buildfile.name=jboss.xml

build.properties:
build.compiler=jikes
deploy.username=stevo
deploy.password=stevo

the project then does

<property file="build.properties/>
<property enviroment="env" />
<property file="system.properties/>

   //loads chamonix.properties
<property file="${deploy.target}.properties/>
//then app server specific stuff
<property file="${deploy.platform}.properties/>

//finally we can call our install routine
<target name="deploy" depends="makewar">
   <ant dir="." buildfile="${install.buildfile.name}" target="deploy" />
</target>

This gives you: dynamic configuration, and property file control. One 
propfile/build file per app server platform, one per system with sys 
config details, one per user with user options.


> What do you mind ? Should I develope with for an ant-contrib task as you
> reject this for ant2
> (http://jakarta.apache.org/ant/ant2/requested-features.html) ?

if ant-contrib tasks work for you, use them.



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org