cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reinhard Poetz <reinh...@apache.org>
Subject Re: Micro-Cocoon ... Corona
Date Thu, 13 Mar 2008 15:40:24 GMT
Reinhard Poetz wrote:
> 
> We at Indoqa have started to think about working on a slimmed down 
> version of Cocoon 2.2 ("Micro-Cocoon").

<snip/>

> Having said this, I want to mention that, for us, the Micro-Cocoon 
> effort is a feasability study, that we will conduct over the next 8 
> weeks. 

Working on "Mirco-Cocoon" was an interesting experience. First Grzegorz, my 
colleagues at Indoqa and I began with a code walk-through. Starting with the 
second day we got our hands dirty and we did a lot of refactorings (remove 
sub-sitemap support, remove sitemap-level components management, remove the 
cocoon-protocol, cut some of the dependencies on Avalon/Excalibur, etc.).

In order to make sure that we don't break any functionality that we want to keep 
working, I wrote integration tests (see [1] for the sitemap and [2] for the 
integration test framework and [3] for the tests) which we let run whenever we 
changed something.

This also gave us the chance to use Cobertura to find out how many lines of 
Cocoon code are actually needed to make the tests run. The (for me) surprising 
result was that of 23581 lines of code in Cocoon core, only 5510 are needed for 
the test cases. See [4] for the full reports.

At the end of the third day we began to disucss how much work is still nessary 
in order to reach the goal of a light-weight Cocoon. Our estimation is that it 
will take somebody, who is familiar with Cocoon, another 20 to 30 days. And, we 
are not sure if this enough time to have a clean codebase at the end.

That was the time when the idea of a rewrite was born. (And as I know it is 
important for Grzegorz I want to say that he wasn't involved into this rewrite 
in any ways.) I know, rewrites are a difficult topic especially in the context 
of open source projects but it was just too tempting. Our time budget was that 
we wanted to invest another three days (since it is Steven, a colleague at 
Indoqa and I, which is 6 days in total) into a rewrite and find out how far it 
will take us and to get another time estimation. So far we have invested about 
4.5 days of those 6 days and the results are promising.

This rewrite that we gave the name "Corona" consists of

  . a pipeline API (that isn't limited to XML pipelines but would also
    support connecting of any types of pipes)
  . a sitemap interpreter that interprets the sitemap language of 2.1/2.2
    (pipeline, match, generate, transform, serialize, redirect, read,
     handle-errors, act)
  . the pipeline API and the sitemap interpreter are useable from within
    *plain Java code* (-> no dependency on the Servlet API) --> if it is used
    outside of a web container, the user has to make sure that there is no
    component that uses the servlet API
  . component lookups are hidden behind an own interface so that any
    component container can be used - as you might guess, our current
    implementation currently uses Spring but writing e.g. an OSGi component
    provider would be simple
  . some basic components (resource reader, file generator, XML serializer, etc.)
  . expression language support in sitemaps
  . thanks to the servlet-service framework, it should work with
  . a demo servlet that uses the sitemap interpreter

Corona is inspired by Cocoon 2.x but doesn't use any of its interfaces. The only 
exception will be the JNet source resolver[5] that we will integrate very soon.

Apart from that we will also integrate the Include-Transformer, the 
XSLTTransformer, provide support for controller implementations, provide 
components to use servlet-services from within pipelines and support pipeline 
caching. Then we should be able to run the tests cases[3] of Micro Cocoon which 
is enough if it is "only" pipeline processing that you need.

So far Corona has been developed mostly by Steven (~ 90 % by him, 10 % by me) 
behind closed doors but we would like to change that, if this community is 
interested in adopting it in this or that way. Is there any interest and if yes, 
how should we proceed?

Any feedback is highly appreciated!


[1] 
http://svn.apache.org/repos/asf/cocoon/whiteboard/micro/misc/cocoon-micro-it-block/src/main/resources/COB-INF/sitemap.xmap

[2] http://svn.apache.org/repos/asf/cocoon/trunk/tools/cocoon-it-fw/
     Consists of two parts: (1) HTMLUnit tests + XPath assertions based on the
     integration test framework of 2.1.x and (2) a Maven plugin that starts and
     stops Jetty.

[3] 
http://svn.apache.org/repos/asf/cocoon/whiteboard/micro/misc/cocoon-webapp/src/test/java/org/apache/cocoon/micro/it/

[4] http://people.apache.org/~reinhard/micro-cocoon-cobertura-report/

[5] http://svn.apache.org/repos/asf/excalibur/trunk/components/sourceresolve/jnet/


-- 
Reinhard Pötz                            Managing Director, {Indoqa} GmbH
                           http://www.indoqa.com/en/people/reinhard.poetz/

Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member, PMC Chair        reinhard@apache.org
_________________________________________________________________________

Mime
View raw message