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
