Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cocoon-dev@xml.apache.org
From: "Marc Portier" <mpo@outerthought.org>
To: <cocoon-dev@xml.apache.org>
Subject: RE: Cocoon apps Web site hosting
Date: Tue, 13 Aug 2002 08:17:54 +0200
Message-ID: <LOEAIGHAMOLFGJLAJOFPMEABDEAA.mpo@outerthought.org>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
In-Reply-To: <B97DE316.10D30%ovidiu@apache.org>
Importance: Normal


> -----Original Message-----
> From: Ovidiu Predescu [mailto:ovidiu@apache.org]
>
> On 8/12/02 5:15 AM, "Marc Portier" <mpo@outerthought.org> wrote:
>
> >> Ovidiu Predescu wrote:
> >>> EUR CVS repository. Some developers might already have their own CVS
> >>> repositories, perhaps at SF, but others may choose to have it
> >> hosted here.
> >>
> >> I don't think the actual localtion of the CVS is particularly important
> >> as long as there is a central place to find out about the projects.
> > +1
> > most of this (mail lists et al.) can be organized at various places
> > the real difference would be in some kind of cocoon in ASP
> setup where the
> > different projects can be ran in their own cocoon environment: showcase
> > running apps before people get it from scratchpad of examples
> would be the
> > differentiator (and the hardest work: different cocoon versions possibly
> > different tomcat combinations...)
> >
> > that and the central website that talks about them.
>
> Yes, Marc, these are the core two things we need to capture.
>
> 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

> to see what I'm talking about:
>
> http://www.mozdev.org/projects.html
>
> 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]/**

> >>> 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 <ovidiu@apache.org>
> http://www.webweavertech.com/ovidiu/weblog/index.html (Weblog)
> http://www.geocities.com/SiliconValley/Monitor/7464/ (Apache,
> GNU, Emacs...)
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org