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.
