You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by ko...@inventivedesigners.com on 2002/08/01 08:44:54 UTC
Re: [Proposal] Cocoon Organization
I second that. IMHO, the 'interactive' build is a good start, but it is not
nearly interactive enough. It would be great if the user could answer
simple yes/no questions to select the components they want and maybe even
preconfigure a few (such as database connections).
I'd implement it myself, if only I had the time :-(
Koen.
"Andrew C.
Oliver" To: cocoon-dev@xml.apache.org
<acoliver@apa cc:
che.org> Subject: Re: [Proposal] Cocoon Organization
31-07-02
21:01
Please
respond to
cocoon-dev
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: cocoon-dev-unsubscribe@xml.apache.org
>For additional commands, email: cocoon-dev-help@xml.apache.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org