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. But of course maybe we can have some intermediate, i.e. a time where we have the blocks, but not the block deployer. There another stylesheet can also help.
I like the idea of generating blocks.properties from gump.xml.
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.
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?
It's not easy as you can see. It's also only a temporary solution.
Joerg
