forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ross Gardler <rgard...@apache.org>
Subject Re: Problems with forrest.properties.xml
Date Wed, 02 Aug 2006 21:18:32 GMT
Thorsten Scherler wrote:
> El mié, 02-08-2006 a las 17:18 +0200, Cyriaque Dupoirieux escribió:
> 
>>le 02/08/2006 14:50 Thorsten Scherler a écrit :
>>
>>>Hi all,
>>>
>>>can somebody explain me what I am doing wrong?
> 
> ...
> 
>>>I do not understand why {projectInfo.changes.includeCommitterList} is
>>>working and not {project:projectInfo.svn.ext}.
>>>
>>>Does somebody has a tip?
>>>  
>>
>>The only difference I can see is that 
>>projectInfo.changes.includeCommitterList is aslo defined in the 
>>default.plugin.properties.xml
>>
>>Cyriaque,
>>
>>>TIA
> 
> 
> Wow, Cyriaque, thank you very much. Well spotted.
> 
> I only defined it for the projectInfo (on a project base), but not in
> default (if no project base can be found). Meaning as long a project has
> this property it is working fine.
> 
> As soon a project does not provide this property and it is not added to
> the default.plugin.properties.xml the input module is throwing an
> exception. I tested on a new seed and not the plugin that is why never
> have seen it working till now where I tried again it on the projectInfo
> plugin. 
> 
> I added the property to the project forrest.properties.xml and it was
> working fine. As soon I removed it from there I got my error (after a
> restart). Then I added it to the default.plugin.properties.xml and it
> was working after a restart.
> 
> Maybe we should change the module the way, that if a property can not
> found it should return "".
> 
> wdyt?
> 
> ... or is this the bug, Ross?

Let me see if I understand:

The error is only thrown if the property is not defined in either 
forrest.properties.xml or default.plugin.properties.xml

If it is defined in one of these then no error occurs.

Assuming that this is correct then no this is not a bug.

Should we make it return an empty string if the property is not set?

I would say no. The reason being that default.forrest.properties.xml is 
intended (at least by me) to be self documenting. If we leave a property 
out then we lose that documentation.

> Further I do not like that the properties cannot be changed in run time
> (I guess caching?). The biggest benefit from a xml based properties
> system is that you change the properties with a form and after reload
> you see the new properties.

Agreed - http://issues.apache.org/jira/browse/FOR-737

> How can we change this or better ask should we change it?

It's not quite as simple as caching the values. There are massive 
implications on performance so it should be configurable, have it turned 
on during development, turn it of in deployment or a static build.

Ross


Mime
View raw message