cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carsten Ziegeler <>
Subject Re: Micro-Cocoon ... Corona
Date Thu, 13 Mar 2008 17:17:43 GMT
Reinhard Poetz wrote:
> 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.
Interesting :)

> 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)
Do you have use cases for this? (Just curious)

>  . 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.
Ah, even cooler :) So far I haven't used JNet myself, so it seems you 
found it usefull. If there is anything missing/not working just let me know.

> 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?
If you don't mind, commit it to the whiteboard. I'm heavily interested 
in the stuff :)


> Any feedback is highly appreciated!
> [1] 

> [2]
>     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] 

> [4]
> [5] 

Carsten Ziegeler

View raw message