cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bertrand Delacretaz <bdelacre...@apache.org>
Subject Re: auto generation of blocks.properties
Date Tue, 11 Nov 2003 09:45:58 GMT
Le Mardi, 11 nov 2003, à 10:30 Europe/Zurich, Joerg Heinicke a écrit :

> On 11.11.2003 08:56, Bertrand Delacretaz wrote:
>
>> Le Mardi, 11 nov 2003, à 00:20 Europe/Zurich, Joerg Heinicke a écrit :
>>> ...Another solution IMO are the complete dependencies in our 
>>> blocks.properties. But maintaining both gump.xml and 
>>> blocks.properties is a pain. The solution is to have one file and to 
>>> generate the other one....
>> +1, actually this info should come from the blocks directly 
>> (metadata), but this is for later...
>
> This stylesheet was especially for the time we don't have the "real" 
> blocks...

Sure - your (temporary, as you mention) solution is fine for now IMHO.

>> ...
>> I'd just add a prominent notice at the beginning of the generated 
>> blocks.properties: "autogenerated - do not edit" or something.
>
> This depends. If it is only a helper target it will be called on 
> demand. It would be the same as a committer is editing the 
> blocks.properties and commits it. Now he needs not to edit it by hand 
> but generate it automatically.

IIUC the scenario when there is a change in block info would be:

1. update gump.xml
2. generate blocks.properties from gump.xml (using helper build target)
3. commit both gump.xml and blocks.properties

Is that what you mean?

In this case a warning is needed in blocks.properties, to describe how 
to correctly handle it.
And a warning in gump.xml, to remind people to regenerate 
blocks.properties upon changes.
Might be ok for a temp solution, gump.xml does not change that often.

> ...It's another issue if it is deeper integrated into the build 
> process. Remove blocks.properties from CVS, starting the generation on 
> the first build, later on it will be updated after an update on 
> gump.xml, the user get's again it local.blocks.properties and *must* 
> change the blocks deployment there. But how to keep it in sync? Adding 
> a warning on the screen if the blocks.properties is newer than 
> local.blocks.properties?

Not sure what you mean by "keep it in sync", Isn't this the same 
problem as now?
Currently if blocks.properties changes, I have to do a diff with my 
local.blocks.properties to see what happened.

-Bertrand

Mime
View raw message