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. -Andy > >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: [EMAIL PROTECTED] >For additional commands, email: [EMAIL PROTECTED] > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
