Marc Portier wrote: >>All projects hosted on the site should look similarly, check out >>MozDev.org > > > 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 (http://www.krysalis.org/forrest) and to a lesser extent the Krysalis one (http://www.krysalis.org, 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 >>insufficient. >> > > > 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! Ross > > >>>>>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 http://outerthought.net/forrest (actually also runs for >>>http://outerthought.net 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. >>>> >>> >>>see http://outerthought.net/forrest/forrest-contract.html >>>I can easily give a hand on setting up the forrestbot conf for different >>>projects >> >>Got it, thanks! >> >>Regards, >>-- >>Ovidiu Predescu <[EMAIL PROTECTED]> >>http://www.webweavertech.com/ovidiu/weblog/index.html (Weblog) >>http://www.geocities.com/SiliconValley/Monitor/7464/ (Apache, >>GNU, Emacs...) >> >> >> >>--------------------------------------------------------------------- >>To unsubscribe, e-mail: [EMAIL PROTECTED] >>For additional commands, email: [EMAIL PROTECTED] >> > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, email: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
