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?
(: A ;)
Stefano Mazzocchi wrote:
> If there is something I don't personally like about Cocoon it's the
> feeling of 'monolithicity' that gives the cocoon.war file and the
> problems that this creates.
>
> Many people find a 12 Mb .war file a little too much and I perfectly
> agree with them: people working 'on top' of cocoon (not inside cocoon),
> would like a better way to *install* their stuff on top and not within
> the war file.
>
> The ideal scenario should be something like this:
>
> 1) install an empty cocoon (with only the core libraries it needs to
> operate).
>
> 2) deploy cocoon web applications (CWA) on top.
>
> In short: inherit the .war pattern and make Cocoon look similar to
> Tomcat than to a servlet. (so, providing a solid IoC pattern of use).
>
> - o -
>
> I was part of the group who designed the .war concept and at that time
> we greatly overlooked the concept of 'inter modularization' of .war
> modules: servlet web applications were 'sealed' as applications, not
> components. Interoperation of .war webapps was *not* taken into
> consideration.... I believe this is the reason why there are tons of
> 'php' webapps and some of them interoperating (see www.horder.org) while
> there are very .war applications that interoperate.
>
> I don't want this to happen with Cocoon.
>
> Like I stated previously, I'd like to see these .cwa archives as
> 'components' that must be assembled in order to provide a functionality.
>
> This is the same pattern that avalon used: components and blocks.
> Components are small-size clusters of classes that provide a single or a
> small number of related services. Blocks are clusters of components that
> provide a more high-level service.
>
> Avalon components are used as-is inside Cocoon, and Cocoon itself can be
> considered an Avalon Block (in fact, actually it's just an inteface away
> to become one!) with Servlet API and CLI wrappers (other wrappers might
> be useful in the future, like a Mailet wrapper, for example).
>
> But the above is a code-oriented view of the architecture.
>
> If we move into a web-oriented view, then each 'stylesheet' or
> 'document' can be seen as a 'transformation' component. A pipeline is
> how they are connected together to operate. A cocoon webapp block can be
> seen as the entire archive made with
>
> - sitemap (xmap)
> - documents (xml, stylesheets, pagesheets, images, etc..)
> - cocoon components (classes)
> - component configurations (xconf)
> - libraries (jar, dll, so)
>
> This RT is made to trigger discussion in the creation of:
>
> 1) an archive format (a-la .war)
> 2) a DTD for cwa deployment descriptors (a-la web.xml)
> 3) tools to create the package
> 4) tools to deploy the packages, check dependencies, guide installation
> and configuration
>
> The major difference between a .war archive and a .cwa archive will be
> the their polymorphic nature: while a .war deployment descriptor is a
> file that describes only the *internals* of the archive, a .cwa
> deployment descriptor will have to include:
>
> 1) what 'behavior' the cwa component implements (indicated as a
> versioned URI), similar to the java concept of classes implementing
> interfaces
>
> 2) what other cwa components this component requires (if any), here the
> 'behavioral URI' is indicated, allowing polymorphism
>
> Imagine a possible scenario of use:
>
> 1) you find a cool cocoon webapp to install on your site
>
> 2) you download the .cwa file
>
> 3) you deploy it on top of your cocoon, indicating where you want to
> 'mount' it in your web site URI space.
>
> 4) if a component that implements the same (versioned!) behavior is
> already present in the system, a choice of overwriting or aborting is
> given.
>
> 5) if not, the component is unpacked and installed and its dependencies
> checked.
>
> 6) all the dependencies are checked, if a behavior is required by the
> component but it's not found in the system, the deployer will connect to
> the cocoon cwa database (hosted on xml.apache.org/cocoon/cwa or similar)
> possibly using a web service and give the user choices about the
> different implementations. The user is given the opportunity to install
> its own implementation of that behavior.
>
> 7) when all dependencies are matched, the component is finally made
> available.
>
> But how do cwa components interoperate?
>
> My idea is to come up with a protocol:
>
> component[role]://path/resource
>
> something like
>
> <match pattern="**">
> <generate type="mailbox" src="{1}"/>
> <transform type="xslt" src="mail2document.xslt"/>
> <transform type="xslt" src="[skin]:/document2html.xslt"/>
> <serialize/>
> </match>
>
> comments?
>
>
--
Antti Koivunen (Mr.) <[EMAIL PROTECTED]>
---------------------------------------------
The song of life might not be a simple one,
but there's plenty of room for improvisation.
---------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
