cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ross Gardler <>
Subject Re: Cocoon apps Web site hosting
Date Tue, 13 Aug 2002 10:09:25 GMT
Marc Portier wrote:
>>All projects hosted on the site should look similarly, check out
> forrest skins should make this snap
> and I would consider it good practice for all projects to think about being
> skinned

Yes, there are two skins actively supported at the moment. The Forrest 
one ( and to a lesser extent the 
Krysalis one (, also used by Avalon I believe). 
There could be a thrid but it would seem to be a waste of energy.

The forrest one would make us look like an Apache site, not a bad thing.

The krysalis one would give us the opportunity to leverage some of the 
efforts Nicola has already put in to setting up a "pre apache" 
community, although this is not focussing on Cocoon alone.

>>The second is how to manage the complexity of having multiple Cocoon
>>versions (I think we can ignore the servlet container difference for the
>>moment, that should not be taken into account IMO). We can have
>>each example
>>app deployed in its own war file, but with today's Cocoon runtime memory
>>size and twenty different applications, 2Gb or RAM will be soon
> mmm, to be really honnest: I was even thinking about separate tomcat
> instances, to make sure apps could be (completely) restarted independant of
> each other
> so we end up talking about a cocoon-app-unit of deployment?
> (and a deployment interface)
> haven't been around long enough, but I was told this has been an on and off
> issue?
> maybe this case gets the itch-level high enough?
> on the other hand: maybe this is a simpel/pragmatic approach:
> - apps are put in jars, in the jar sits a subsitemap and all other stuff
> needed (maybe in predefined COCOON-INF subdirs)
> - little process (web trigger?) knows about how to unpack it, and deploy it
> - probably using /app/ as an automount or something
> there is an issue of overwriting /WEB-INF/ (so cross-app-space) classes and
> libs, no?
> guess we'll just need to manage this (by hand or discipline I mean), right?
> Maybe it could be (partially) done by means of the cocoon-apps cvs repo?
> as for the different versions of cocoon that will need to be separate wars,
> so we'll end up with some
> http://[cocoon-app-site].org/cocoon-[versioncode]/app/[appname]/**

This really does make me think we need individual servers, linked 
through a web-ring, with a central point for reference. The server I am 
offering is *way* below suitable spec and is not the best connected 
machine in the world. It will handle a moderate amount of trafic, but a 
couple of very succesful apps could make it grind to a halt!


>>>>>How do people publish their content?
>>>>Forrest is getting closer to making the automatic updating of content
>>>>from CVS repositories.
>>>forrestbot is running since euh.. week or 2
>>>it's probably not the last incarnation of the thing, so there could be
>>>changes in the future, but it's running very stable over at our
>>server to
>>>produce (actually also runs for
>>> with different content and skin)
>>Forrest can take care of publishing static documentation, but how about
>>deploying new functionality in an application? Especially those whose data
>>source is stored on the live system. I was arguing that we need a staging
>>area for such things, where people can actually test the
>>application before
>>pushing it on the live site.
> different view:
> - we use forrest only for the documentation. and we use it as is to generate
> static content
>   so pretty much of http://[cocoon-app-site].org/ would be static content
> pushed up there by the forrestbot (every 2h say)
> - only the apps would be doing dynamic/interactive stuff
> - as for staging/testing: couldn't we hope for that to have been done by the
> developer before checking in? probably he'll need to be able to specify some
> branch identifier to separate 'approoved and checked' from 'wip'
>   (all in all, we might consider running the same environment on different
> portnumber, so one could have those two different branches indeed up and
> running as well?)
> uhuh, this makes me think again about the "little process" mentioned earlier
> have been running around with the idea to extract the bot ideas from
> forrestbot and maybe combine them with how gump is working to build some
> kind of a generic bot system that could be checking out code from a cvs repo
> and then start calling some specific ant targets in those different
> retrieved projects. (forrestot more or less does this, but is very
> forrest-only of course)
> so maybe the "little process" would be something that just
> - cvs co cocoon-apps
> - knows about the apps in there (by means of local file, or by means of how
> the repo is organized: dir-naming/special-descriptor.xml or the like)
>   to know about would be: preferred cocoon version to run on, app-name,
> (list-off) ant targets to call to have it build/deploy locally?
>   this would more or less only require us to have some known ant-properties
> set to tell these app-specific ant targets where they need to store stuff.
> (app-context-dir, ...)
> (euh, if we really have cocoon-apps, then there could just be a main
> build.xml that calls upon the others.)
> this approach would probably also allow apps to have ddl statements executed
> against some mysql or whatever (as long as people can express it in ant,
> right?)
>>>>>It would be great if
>>>>>we can get some thoughts on what we need here.
>>>>I think the whole question of how and when things are published need to
>>>>be handled by Forrest. Perhaps people more active than I can comment on
>>>>how this would work.
>>>I can easily give a hand on setting up the forrestbot conf for different
>>Got it, thanks!
>>Ovidiu Predescu <>
>> (Weblog)
>> (Apache,
>>GNU, Emacs...)
>>To unsubscribe, e-mail:
>>For additional commands, email:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, email:

To unsubscribe, e-mail:
For additional commands, email:

View raw message