cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bertrand Delacretaz <bdelacre...@apache.org>
Subject [RT] Goals for the next major release of Cocoon
Date Tue, 19 Jul 2005 11:08:27 GMT
== Intro ==
This is not really an [RT] but a summary of a discussion that we 
(Gianugo, Upayavira, Reinhard, Daniel, Alfred, Bertrand, Marcus, 
Carsten, Giacomo, Sylvain and Torsten) just had at the Blockathon. See 
also http://wiki.apache.org/cocoon/Blockathon2005Report

Comments are welcome of course - we want the whole community to be 
involved in this, if possible, not only the Blockathon participants.

These goals have nothing to do with OSGI per se, we tried to stick to 
the high-level goals that have been ours for a while (read "Real 
Blocks"), but write them down again to make sure we keep the focus and 
agree on the important things.

== Goals ==
Order is not relevant in the following list, we feel that these are all 
"must have" goals, although there are some options or variants in the 
goals which might have lower priority.

1) Smaller core
Can mean several things:
-Smaller source distribution
-Smaller binary distribution
-Small deployment for simple things (e.g. simple XSLT processing)

2) Pluggable Blocks (aka Real Blocks)
-At deployment time (must have: download blocks from some repository)
-At runtime (might come later, same thing while Cocoon is running)

3) Quick edit -> test cycle
Including java code, XSLT transforms, sitemaps, flowscript, etc.

4) Isolated blocks
Selective exporting of interfaces and classes, while hiding "internal" 
classes used by the block.

5) Intelligent sharing of jars
Solve "jar hell", where different versions of a given jar can be 
present due to environment problems of conflicting requirements.

6) Dependency resolution
Based on version numbers, load the correct version of a block or jar.
Make it possible for several versions of a block or jar to be used in a 
deployed application.

7) Compatiblity with existing apps
Can be either static (based on upgrade scripts) or dynamic, based on 
runtime mappings.

War file deployement (J2EE) is a must have.

== Vision for the near future ==
-Explore OSGI for fulfilling these goals
-Keep an exit path in case we're not happy with the results
-Let the framework be our slave, not the opposite

-Bertrand



Mime
View raw message