An alternative proposal:
- Cocoon 2 Micro Edition (C2ME): basic functionality/components
- Cocoon 2 Standard Edition (C2SE): most frequently used
functionality/components
- Cocoon 2 Enterprise Edition (C2EE): complete suit, including flow
control, form handling, DB-stuff, etc.
But this does not require any sub-projects, but a more sophisticated build.
I don't think that development of Cocoon itself will be any easier if it'll
be split into subprojects. How would you syncronize all of them? Are there
any really big parts that can be separated and developed independently?..
Konstantin
From: "Leo Sutic" <[EMAIL PROTECTED]>
>
>
> > From: Gianugo Rabellino [mailto:[EMAIL PROTECTED]]
> >
> > 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.
> >
> > Yes, +1, go for it, hippy-ya-ye-o! This is badly needed.
> >
> > The problem is how to split actually. Based on functionality (i.e
> > cocoon-sql.jar, cocoon-xmldb.jar, cocoon-ldap.jar), by Cocoon role
> > (cocoon-generators.jar, cocoon-actions.jar), by status
> > (cocoon-stable.jar, cocoon-scratchpad.jar, cocoon-beta.jar)
> > or by what?
>
> By functionality and status:
>
> cocoon-sql.jar
> cocoon-sql-scratchpad.jar
> cocoon.jar
> cocoon-scratchpad.jar
> .
> .
> .
>
> I agree, it is a big job... But *badly* needed.
>
> /LS
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
