[Yanel-dev] Setting of YANEL_HOME

Guillaume Déflache guillaume.deflache at wyona.com
Wed Mar 4 12:48:15 CET 2009


Michael Wechner schrieb:
> Alec Bickerton schrieb:
>> Michael Wechner wrote:
>>  
>>> simon litwan schrieb:
>>>    
>>>> Michael Wechner schrieb:
>>>>      
>>>>> Hi
>>>>>
>>>>> I have added the check for YANEL_HOME within build.sh, whereas it's
>>>>> optional and one can continue the build by pressing enter/return key.
>>>>>
>>>>> I assume that Hudson will fail now, because YANEL_HOME is not set,
>>>>> right? For this I see two possibilities, either
>>>>> set YANEL_HOME also within Hudson and make this check somehow
>>>>> configurable.
>>>>>         
>>>> i rather would solve this with an ant property.
>>>>       
>>> ok. Can you describe it a bit more detailed?
>>>     
>>
>> If I understand correctly. Your suggesting we each create in our home
>> directories a property file.
>>   
> 
> you mean for example
> 
> /home/michi/.ant-global.properties
> 
> and referencing it like
> 
> <property file="${user.home}/.ant-global.properties"/>
> 
> right?
> 
> Sounds good to me. Will try to change it.
> 
> Thanks
> 
> Michael

I think we do not need $HOME/.ant-global.properties anymore, at least 
for setting ${yanel.home}, because
for "build -f" we force it to the script directory anyway.
So if you use the script from the Yanel source distribution you want to 
use to run the resource-type Ant script, you no longer need to indicate 
where the Yanel source is,e.g.:
---8<---
cd /path/to/Yanel-working-copy # granted, we should not need to cd, but 
that's another problem
./yanel.sh build -f src/resources/file/build.xml
---8<---
...simply works nowadays.

>> In this file you would have all your local settings
>> e.g.
>>
>> yanel.home=/home/alec/code/yanel_trunk
>> tomcat.home=/opt/tomcat/

Using another Tomcat is already possible from local.build.properties, 
and I am not sure it makes sense for it to be a global (default) setting 
anyway.

Also AFAICS the way it is implemented ATM is that user-specific 
properties override the Yanel source properties, which is backwards 
IMHO: these should be fallback settings, not globally-enforced settings.


>> Etc...
>>
>> Then the build.sh first tries to read these properties using the ant
>> variable ${user.home}.
>>
>> Immediately after it will read a default properties file and set
>> whatever was not included.
>>
>> I'm quite familiar with this approach and find it works exceptionally 
>> well.
>>
>> The same file can be read by a realm specific build.xml file so that we
>> would only need to call ant in the realms directory to build and  then
>> link to yanel/realms.

This might still be interesting, but so far AFAIK arbitrary Java code 
still cannot be associated to a realm (is there a Bugzilla issue for 
this?) and the realm itself is not even a build artifact ( see 
http://bugzilla.wyona.com/cgi-bin/bugzilla/show_bug.cgi?id=6224 for some 
other reason for changing this )


More information about the Yanel-development mailing list