Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cocoon-dev@xml.apache.org
Message-ID: <3C7CEE39.4A3C1BF3@apache.org>
Date: Wed, 27 Feb 2002 15:33:29 +0100
From: Stefano Mazzocchi <stefano@apache.org>
MIME-Version: 1.0
To: cocoon-dev@xml.apache.org
Subject: Re: [RT] Cocoon Web Applications
References: <3C79200A.64965AFD@apache.org> <3C7A336D.5070307@users.sf.net>
 <3C7B576F.F3689E46@apache.org> <3C7BD538.103@users.sf.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Antti Koivunen wrote:
> 
> Stefano Mazzocchi wrote:
> > Antti Koivunen wrote:
> >
> >>Stefano,
> >>
> >>I agree with the objectives you described, but I'd be careful not to
> >>turn Cocoon into a package management tool. AIU, .wars and .ears were
> >>designed to be self-contained deployable archives, and as such, are
> >>quite useful for many things, such as rolling out new versions, moving
> >>from testing to QA, etc.
> >>
> >>It's likely that many users will want to continue to prepackage their
> >>.wars (and .ears), but I agree that for Cocoon this process could be
> >>facilitated, possibly with something like 'CWA's.
> >>
> >>Based on this, and other discussion on this list, I think it could be
> >>useful to have some kind of installation/configuration tool for Cocoon.
> >>It shouldn't be too difficult to implement with a clear definition of
> >>core libraries, optional modules and dependencies (within the same
> >>Cocoon distribution). At first, it could be a simple client app that
> >>just does the following:
> >>
> >>   1. Download a set of files describing the Cocoon distribution.
> >>   2. Select the desired modules (in addition to the core fileset).
> >>   3. Check the dependencies (file-level, within the same distribution).
> >>   4. Create the directory structure and download the required files.
> >>   5. Create a sample sitemap and xconf for the selected modules.
> >>
> >>The tool could of course also be used locally and it would be relatively
> >>easy to later add support for "CWA modules". Implementing the above
> >>should also be pretty straightforward. Would this be a good first step?
> >>
> >
> > Well, yes, but that's not what I want.
> >
> > What you describe above is a sort-of apt-get for cocoon.
> 
> Well, more of a way of increasing the modularity and internal
> consistency of the Cocoon distribution (as opposed to a complete package
> management solution).

ok

>  > ... Sure, apt-get
>  > is way cool, but it's a packaging solution, not a component model.
> 
> Exactly. I meant to emphasize that .wars have their purpose and that
> packaging is different from modularity, you can have one without the
> other (although it makes little sense to have the former without the
> latter).

Agreed, but I'd rather have both, thus my reasoning.

> > What I want is polymorphic behavior of webapp modules!
> >
> > There is *no* technology in the world that gives me this for the web!
> > ASAIK, at least.
> 
> I'm all for increasing the modularity and extensibility of Cocoon, and I
> like e.g. the concept of "skins", but I'm not sure that "Web
> Application" is the right "unit" to use. I mean, it's just as likely
> that Cocoon is used as a part of a single webapp, and I'd also like to
> see the same modularity apply to other components, e.g. the likes of hsqldb.

Of course. Modularity should be both 'vertical' (as with the 'skin'
approach) and 'horizontal' (as with hsqldb examples or a portal
application).... but I think my proposal solves both at the same time.

> If CWA is defined to be "something that provides additional
> functionality" for the Cocoon instance, then I think it's a good idea
> (but perhaps better named to "Cocoon Web Component" or CWC, respectively).

I like 'Cocoon Web Component', yeah, that's a good name.
 
> > Sure, once you have polymorphic behavior for webapp modules, you have to
> > have some sort of 'package manager' (in the apt-get sense): doing it by
> > hand is a horrible task.
>  >
> > But a package manager alone would not something that would please my
> > search for a viable way to make cocoon web applications easily reused
> > between different projects.
> 
> I agree (and would love to see that repository of Cocoon modules :)

Exactly and I think that in order to make sure they interoperate in a
nice and easy way, CWC polymorphism would be way cool!

-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<stefano@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------


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