> -----Original Message----- > From: Morrison, John [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, March 12, 2002 11:11 AM > To: '[EMAIL PROTECTED]' > Subject: [VOTE] Seperate Contrib/optional area/cvs (was: RE: POI > Serialization code committed) > > > OK, lets split this thread. > > Should we seperate the contrib/optional stuff from core? > > +1
Interesting, history repeats. Ok, I started a vote on this several months ago and noone voted +1..sniff.. Before I can give my +1 I'm interested in how you will handle the optional jar files. For example if you have two optional components which both require the same optional jar? Has each component it's own lib directory, do they share a common lib directory? > > Should it be located in a seperate cvs? > > +1 > -1 See Thorstens reply. Carsten > J. > > > From: Sylvain Wallez [mailto:[EMAIL PROTECTED]] > > Nicola Ken Barozzi wrote: > > >From: "Steven Noels" <[EMAIL PROTECTED]> > > >>Andy wrote: > > >>>Steven wrote: > > >>>>So I am all unofficial +1 for having a separate module for Cocoon > > >>>>contributions, where we can add the POI integration work, > > if enough > > >>>>people step up as a maintainer. > > >>>> > > >>>+1 if there are enough to justify it. > > >>> > > >>I hope the remainder of my arguments are not lost, however. This is > > >>suboptimal solution until POI admits it really should become part of > > >>their own codebase. Only the real Cocoon-specific classes should > > >>eventually go into the contrib section of Cocoon CVS. POI > > supporting XML > > >>is not in scope for Cocoon, neither. > > >> > > > > > >Cocoon is becoming overcrowded with optional components, and > > this is a fact. > > >For this, I think that we need a contrib section, which is > > optimal for > > >Cocoon IMHO. In the near future it will be the famous "Cocoon Blocks" > > >section. > > > > > >I'm +1 for this. I'm refactoring examples in this direction, > > and will commit > > >ASAP. > > > > > > > +1 also. But IMO we should distinguish "contrib" and "optional" : > > - "contrib" means donated (and accepted) code that didn't > > find a better > > place, but is not actively maintained by the Cocoon team, > > - "optional" means code that is related to a third party > > library that is > > isn't core to Cocoon, and supported and maintained by the team. > > > > We have also to be very careful that these sections don't > > become a giant > > mess, and that they have good visibility so that users know > > what's inside. > > > ======================================================================= > Information in this email and any attachments are confidential, and may > not be copied or used by anyone other than the addressee, nor disclosed > to any third party without our permission. There is no intention to > create any legally binding contract or other commitment through the use > of this email. > > Experian Limited (registration number 653331). > Registered office: Talbot House, Talbot Street, Nottingham NG1 5HF > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, email: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
