cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carsten Ziegeler" <cziege...@s-und-n.de>
Subject RE: [VOTE] Seperate Contrib/optional area/cvs (was: RE: POI Serialization code committed)
Date Tue, 12 Mar 2002 11:57:58 GMT
> -----Original Message-----
> From: Morrison, John [mailto:John.Morrison@uk.experian.com]
> Sent: Tuesday, March 12, 2002 11:11 AM
> To: 'cocoon-dev@xml.apache.org'
> 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:sylvain.wallez@anyware-tech.com]
> > Nicola Ken Barozzi wrote:
> > >From: "Steven Noels" <stevenn@outerthought.org>
> > >>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: 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


Mime
View raw message