cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: [RT] Goals for the next major release of Cocoon
Date Tue, 19 Jul 2005 12:27:48 GMT
Bertrand Delacretaz wrote:
> == 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

What can I say: <applause/> :-)

-- 
Stefano.


Mime
View raw message