On Tue, 2003-09-09 at 17:14, Geoff Howard wrote: > Bruno Dumon wrote: > > On Sat, 2003-08-30 at 04:57, Geoff Howard wrote: > > <snip/> > > > >>But this brings up another point - what to do if the wiring.xml and > >>others is deleted? Presumably, all blocks are "uninstalled" in this > >>state, but what does this do to persistence requirements. > >> > >>Also, how to recreate the deploy step efficiently? For example: > >> > >>You deploy a block with some dependencies and configuration. The block > >>deploy process walks you through setting configs and resolving > >>dependencies. You then have no record of these deployment choices > >>except in wiring.xml which is not meant for human consumption. Perhaps > >>it would be good to record these human-step deployment time > >>configurations in a conf file which could be easily reprocessed to > >>easily re-deploy all blocks to their last configuration. > > > > > > I think the conf file you're speaking of here is simply the wiring.xml > > file itself? Remember, the block deployer has read-write access to this > > file, so it can first read the existing information, then let the > > administrator modify it, and then write it back. It's not like each time > > you want to modify the configuration of one block you'll have to > > re-enter all the parameters for other blocks as well. > > Ugh, I see now that I didn't explain well the scenario I was thinking of > and now can't remember! IIRC I was trying to think through the process > of replication and/or staging. In this case, would I copy over > wiring.xml and all blocks directories? (presumably) But, what if some > of the deploy-time configurations need to change on the way? For > instance, on a staging server, you use a different database. So, I was > just trying to get a picture in my head of how that would work and what > the pitfalls were.
Aha, I understand the issue now. And next to staging and live servers there are of course also the development servers or workstations. So there are parameters which will be common for all installations and parameters which can be different, and it would indeed be useful if we can feed those common parameters to the block deployer, so that only system-dependent parameters need to be completed. Hmm, now that I think of it, it would also be useful to feed the system-dependent parameters to the block deployer, because I don't want to re-enter those either when I do a "clean" block deploy. Basically what I'm arriving at is that the block deployer should be able to run in an interaction-less mode by providing it with input files giving it all the information. Or then maybe it becomes more useful to write the wiring.xml by hand and place a few @token@'s here and there which are replaced by an ant script based on the values in a local.properties file. Need to think more about this... -- Bruno Dumon http://outerthought.org/ Outerthought - Open Source, Java & XML Competence Support Center [EMAIL PROTECTED] [EMAIL PROTECTED]
