cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: [RT] Implementing Cocoon Blocks
Date Sat, 13 Sep 2003 13:37:04 GMT

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 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 $ and have a .properties file which 
> defines  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 

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.


View raw message