> From: Vadim Gritsenko [mailto:[EMAIL PROTECTED]]
>
> > From: Christian Haul [mailto:[EMAIL PROTECTED]]
> >
> > On 31.Jul.2002 -- 09:27 AM, Berin Loritsch wrote:
> > > We should split Cocoon into core development and component
> development
> > > efforts, much like Avalon does with Framework and Excalibur. That
> will
> > > allow the components to be packaged in jars that serve a similar
> > > purpose.
> >
> > In general, I agree. But I fear that many functional
> subprojects are
> > too small to be handled seperately.
> >
> > > Things like all the database related components should be in their
> own
> > > mini-project. Each mini-project has its own
> documentation, and its
> own
> >
> > Which is a good example: We have ESQL (depends on XSP),
> > SQLTransformer, and two sets of Database*Actions. Putting
> all in one
> > subproject could be done. But from the deployment
> perspective, I would
> > perhaps use one or two, hardly all of them.
>
> Yes, you may use only one or two. But think about it: right
> now there is no one, commonly shared syntax for these two
> (esql and transformer), and they have no common roots, they
> are not well integrated.
>
> If you to put esql and sql transformer into different
> subprojects, then situation will just get worse. They must be
> in the same subproject, and should be unified and integrated
> as much as possible, to reduce repetitive code and make
> maintainance / feature additions easy.
>
>
> IIRC, somebody (Andrew?) was about to integrate these two.
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]
