I agree with Carsten: +1 (seperate the contrib/optional stuff from core?) -1 (Should it be located in a seperate cvs?)
--- Carsten Ziegeler <[EMAIL PROTECTED]> wrote: > > -----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] > ===== Davanum Srinivas - http://xml.apache.org/~dims/ __________________________________________________ Do You Yahoo!? Try FREE Yahoo! Mail - the world's greatest free email! http://mail.yahoo.com/ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
