cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steven Noels <>
Subject Re: Planet Cocoon license and reuse of docs
Date Fri, 27 May 2005 12:47:01 GMT
On 27 May 2005, at 03:24, Antonio Gallardo wrote:

> I believe, I am reading this mail with a time delay. What is clear to 
> me
> is that I don't received a root password of the cocoon Solaris zone. 
> And I
> don't know if the zone is already up. If I becomes the root of our 
> zone,
> then I will be glad to provide all the necessary support to materialize
> this effort.

Great. Maybe I understated my own sysadmin capabilities - if Solaris is 
a wee bit Unix-like, I'll find my way around and I'll be able to help 
out. And I've got experience using Wrapper ( to 
deploy Java apps as services, running under their own user - I use this 
extensively at (on Debian Linux).

AFAIU, setup has been aborted prematurely, and infra@ folks are still 
discussing ways to handle password handover. So no zone and password as 
of now, but it's somewhere in the pipeline.

> As pointed before, I believe we can also setup there some cocoon demo
> sites. I know, this is OT here, but I think it will be good to have 3
> demos:
> 1- Current released version
> 2- Daily SVN 2.1.x
> 3- Daily SVN 2.2.x
> Having up demo sites are a powerful marketing tool. And I am sure all 
> of
> us know that. ;-)
> How to do that? I think we have 3 posibilities:
> A. On the same servlet container instalation.


> C. Diferent containers using diferent ports for each instalation.


I know my way around mod_proxy and friends to set this up properly. 
Seems like the box is quite powerful, so running a few Java VMs 
alongside each other shouldn't be a problem. And Daisy needs 3 of them 
anyhow (OpenJMS/repo server/Cocoon).

Daisy binaries come with a precompiled Cocoon distribution, so setup is 
rather easy - we'll just have to juggle around port numbers.

I volunteer to hand-migrate Helma's 
stuff, and I'll get back to the list to discuss Daisy configuration 
(mostly metadata, document types, collections, branches and languages, 
and how we'll configure the draft/publish/comment/ACL to make it easy 
and manageable). Once we have that stabilized, and work on the 
refactoring of the Daisy publishing code has started, we can look at 
skinning - upsofar the contract for skin-implementors is a bit too 
volatile IMO. So I'd propose to just stick with the default layout, or 
only tweak the CSS.

People interested in co-administering Daisy (users, creation of 
variants, ACL rules, sites): please stand up.

Steven Noels                  
Outerthought - Open Source Java & XML            An Orixo Member
Read my weblog at  
stevenn at                stevenn at

View raw message