On Wednesday, Sep 10, 2003, at 13:47 Europe/Rome, Geoff Howard wrote:
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.
Exactly.
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.
Although the stated intention was that wiring.xml was not meant to be edited by hand (except by "experts" suppose). So, wild thinking of options:
- ant filtering tokens as you propose
- good old xml xpath-based manipulation between servers (xsl or xpatch tool)
- option to deploy with variables/propertynames instead of literal values? For instance, if for servername you can either provide a literal value or $property.name and have a .properties file which defines property.name=mydevserver.com. That way, you manage only which properties file exists on each server?
Need to think more about this...
Yup, and there are probably a number of solutions which could work without modifying the wiring.xml structure at all so it could probably be revisited at implementation time.
it is possible to add a namespaced "local" attribute to the configurations in the wiring file so that if a staging and/or cluster replication action is required, the block deployer can ask for the parameters again when replication the block installation on another machine.
But I would suggest to start with a single machine setup and then increase the functionality with user requirements, we already have enough things to do.
-- Stefano.
