You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by "Morrison, John" <Jo...@uk.experian.com> on 2002/03/12 11:10:50 UTC
[VOTE] Seperate Contrib/optional area/cvs (was: RE: POI Serializa
tion code committed)
OK, lets split this thread.
Should we seperate the contrib/optional stuff from core?
+1
Should it be located in a seperate cvs?
+1
J.
> From: Sylvain Wallez [mailto:sylvain.wallez@anyware-tech.com]
> Nicola Ken Barozzi wrote:
> >From: "Steven Noels" <st...@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
Re: [VOTE] Seperate Contrib/optional area/cvs (was: RE: POI
Serialization code committed)
Posted by Torsten Curdt <tc...@dff.st>.
On Tue, 12 Mar 2002, Nicola Ken Barozzi wrote:
> From: "Morrison, John" <Jo...@uk.experian.com>
>
> > Should we seperate the contrib/optional stuff from core?
> >
> > +1
>
> +1
+1
> > Should it be located in a seperate cvs?
> >
> > +1
>
> +1
-1 a different area is fine but since it's optional for *cocoon*
why not keep it in the same cvs? ...I admit: I am just too lazy to keep
track of another repository ;)
--
Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [VOTE] Seperate Contrib/optional area/cvs (was: RE: POI Serialization code committed)
Posted by Nicola Ken Barozzi <ni...@apache.org>.
From: "Morrison, John" <Jo...@uk.experian.com>
> Should we seperate the contrib/optional stuff from core?
>
> +1
+1
> Should it be located in a seperate cvs?
>
> +1
+1
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [VOTE] Seperate Contrib/optional area/cvs (was: RE: POI Serialization code committed)
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Davanum Srinivas wrote:
>I agree with Carsten:
>
>+1 (seperate the contrib/optional stuff from core?)
>-1 (Should it be located in a seperate cvs?)
>
Same here :
+1 for separation of contrib/optional stuff
-1 for a separate CVS. The amount of code doesn't justify it and it
would decrease its visibility. However, this can be reconsidered in the
future if needed (see Avalon apps that now have their own repository).
Sylvain
--
Sylvain Wallez
Anyware Technologies Apache Cocoon
http://www.anyware-tech.com mailto:sylvain@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [VOTE] Seperate Contrib/optional area/cvs (was: RE: POI Serialization code committed)
Posted by Davanum Srinivas <di...@yahoo.com>.
I agree with Carsten:
+1 (seperate the contrib/optional stuff from core?)
-1 (Should it be located in a seperate cvs?)
--- Carsten Ziegeler <cz...@s-und-n.de> wrote:
> > -----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" <st...@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
>
=====
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: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [VOTE] Seperate Contrib/optional area/cvs (was: RE: POI Serialization code committed)
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
> -----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" <st...@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