Apache Forrest WikiRenderer
 
   

DistributingCocoonApplications

PDF
PDF

Random Thoughtsfrom Leigh Doddsabout how one might go about distributing a Cocoonapplication.

Scenario

Lets begin a thought experiment:

I'm building a web application based on the Cocoon architecture, which I'm intending to be given away as open source (of course!). I craft my application which ends up consisting of a number of SitemapPipelines, some XSLTstylesheets, assorted web pages and images, and perhaps a custom Componentor three.

How do I package up this application so that others can make use of it? What options do I have?

Options

The available options seem to be:

  1. Complete Webapp

-- a complete web application that is essentially a Cocoon distribution customised to run my application rather than the default set of examples.

  1. Donate to Cocoon

-- I could donate my application directly to the Cocoon project. It could then be added to the standard Cocoon distribution, perhaps initially in the scratchpad. That way everyone who downloads Cocoon will have my application.

  1. Cocoon Bundle

-- a zip/tar file consisting of just my application files, with instructions about how to configure an existing Cocoon instance to run my application, e.g. by mountingmy sitemap.

What are the cost/benefits of each scenario?

The Complete Webapp option seems to be the best if I want people not already running Cocoon to run my application. The application distro is obviously much bigger, and existing Cocoon users may just want to add it to an existing instance.

Donating to Cocoon has the obvious benefit that a lot more people will see the application: it will be highly visible. It will already be pre-configured, so there's less involved in setting it up. However this makes the Cocoon distro itself much more complex, especially for people who aren't interested in my applications functionality.

Using a Cocoon Bundle has the advantage that its easy for existing Cocoon users to deploy. But has the disadvantage that non-Cocoon users won't be able to easily use it.

Conclusions and Suggestions

We might conclude from this that if I want to distribute a Cocoon application as widely as possible then I just simply bundle it as a Complete Webapp. But it's also worth my while to take the time to produce a Cocoon Bundle and supporting installation docs.

Applying this thinking to Cocoon itself it seems that one good way to modularise the application is to simply modularise the distribution along these lines. There could be a 'complete' distro that simply has everything -- basically the current situation. However it would also be worth having an 'empty' distro that has nothing more than a Minimal Sitemap. There can then be separate Cocoon Bundles for additional self-contained functionality.

Another way to look at this idea is to think of Cocoon as a container, similar to a Servlet or EJB container: these application have a default install with little/no functionality, but often have separately downloadable examples. Application providers can bundle their applications for automatic deployment into a container.

Further Thoughts

Deploying a Cocoon Bundle could be an automated process. To mount the application I either need to:

  1. copy the applications additional pipelines into the root sitemap, or
  2. mount the application as a sub-sitemap

Both of these operations could be achieved with a simple XSLT stylesheet, possibly fronted by an Antscript. In the first case the stylesheet could just copy over the appropriate pipelines from one document to the other. In the second case, the stylesheet would just add the appropriate <map:mount>instructions [1] .

Imagine that this application deployment functionality is a standard part of Cocoon [2] . As an adminstrator I could use this functionality to automatically deploy (perhaps even download as well, cf: Debian package management) other peoples applications, those examples in which I'm interested, and even the documentation.

----

I've been mulling this over for a while, but the recent cocoon-dev discussions about modularising Cocoon (amongst other things) prompted me to actually write it down.

I'm in the process of writing a couple of Cocoon based applications, so wanted to get the options straight in my head. I prefer the Cocoon Bundle option myself

Comments very much appreciated.

-- Leigh Dodds

----

See also

how Blocks could help distributing applications

----

Readers comments

Automounting simple applications-- Bertrand Delacretaz

In this second case, if the application consists only of a sitemap and static files, copying them to a new directory under the mount subdirectory of a standard Cocoon installation is sufficient (see UnderstandingCocoonMounts).

Requirements for auto-installing Bundles-- Bertrand Delacretaz

Here's a tentative list of what Cocoon needs to be able to auto-install Bundle XYZ:

  • Add entries to the main sitemap, marking them as created by Bundle XYZ so they can be removed automatically. Should be able to query the user for variable values.
  • Same for cocoon.xconf (or add "sub-xconf files" owned by Bundle XYZ).
  • Add jar files to the appropriate directory, marking them as owned by Bundle XYZ so they can be removed automatically.
  • Restart Cocoon or otherwise reload the new jar files

Instead of modifying the existing files, it might be easier to create a new XYZ subdirectory under WEB-INF, and put all the Bundle configuration and jar files there. This requires changes to the sitemap and xconf handling though.

An interesting use-case for this is installing a Bundle that accesses a database using a new JDBC driver.This requires changes to sitemap, xconf and a new jar, and database information provided by the user during installation.

----

From a not-the-smartest-user-in-the-universe perspective:

If I recieve a "Cocoon-app" from somewhere, I want to:

  1. drop it in a subdirectory / upload it via webdav to some directory I mean context.

Period. No restarts, no fiddling with the main site map, no configuration of the cocoon "kernel", only configuration of the new cocoon app.

Naturally one might have to do other configurations in the environment that the cocoon app might need, but that's a completely different story.

The important thing is that one should not have to risk to break anything in the existing cocoon installation, when installing new things.

/Ola Berg

---- What about "hot-deployment"? I think that the TreeProcessor and the ComponentManager used in Cocoon should be accesible and have hooks to an installer-thread. This thread could itself be a component that is bootstrapped by the CM. It listens for the bundle in the dropin subdirectory and automounts in .xmap and .xconf AND adds the component into the already running CM AND mounts the new sitemap components into the already running TreeProcessor (the last step shouldn´t be needed since the TreeProcessor checks for updates to the sitemap.)

/Mats Norén