cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew C. Oliver" <>
Subject Re: [Proposal] Cocoon Organization
Date Wed, 31 Jul 2002 19:01:20 GMT
This sounds like it could be an undue burden on the users.  I think what 
really needs to be done
is an improvement in the build system.  Something more aken to the Linux 
"MenuConfig" or "XConfig"
rather than try and break the project up at this point.

I think what will probably happen is it will become a tremendous pain 
for users to get it all
working together.  And eventually there will be "distributions" of 
sorts.  If you're sure thats
what you really want.... Thats fine, but plan the distributions up front 
instead of having those
years of meandering that Linux et al had when it was a royal pain to set 
up (pre-REAL distributions).  The only way it
was secure was that no script kiddies could run it either ;-)

If Cocoon wants to do the same. Avalon is a bad pattern to follow as no 
one outside of avalon understands the various
pieces either.


>I was thinking at least along the lines of required libraries.
>Therefore since all the database related stuff requires a
>DB driver library, then all the DB stuff would be in one
>subproject.  I.e. ESQL and SQLTransformer would live together.
>Using that line of thought, The PDF/PNG generation would go
>into a "graphical" package (i.e. the output stream is not
>a form of text like XML/HTML).  FOP uses Batik, so they are
>somewhat required to be together.
>Here is my stab at the separation (and I don't have the full
>list of components either):
>database: All DB related actions/transformers/generators/readers/
>          logicsheets/etc.
>graphical: FOP & Batik related stuff
>portal: All the sun* stuff
>forms: All the form validation/processing tools
>Essentially, we need to break down the jar file dependency graph,
>and use that as a starting point.  If a jar file is required by
>another jar file (like FOP needs Batik), they should be grouped
>together along with all their associated Cocoon components.
>Keep in mind that separating the back end from the front end
>(i.e. the servlet/environment files and the cli/environment
>files) we can have a centrally installed Cocoon and several
>[much] lighter weight WAR files that use Cocoon.  But that's
>only what I like.
>To unsubscribe, e-mail:
>For additional commands, email:

To unsubscribe, e-mail:
For additional commands, email:

View raw message