RE: [VOTE] Seperate Contrib/optional area/cvs (was: RE: POI Seria lization code committed)

["Morrison, John" <Jo...@uk.experian.com>]

OK.

Seperate the contrib/optional stuff from core?
  Nicola: it looks like everyone (so far ;) is in favour of
seperating this. I know you were/are looking at doing it; how
far have you got?

Should it be located in a seperate cvs?
  Enough -1's.  It stays in the current cvs.  If there's
enough cause in the future, this can be rethought.

Now, back to the POI problem... :)

J.


> -----Original Message-----
> From: Sylvain Wallez [mailto:sylvain.wallez@anyware-tech.com]
> Sent: Tuesday, 12 March 2002 12:58 pm
> To: cocoon-dev@xml.apache.org
> Subject: Re: [VOTE] Seperate Contrib/optional area/cvs (was: RE: POI
> Serialization code committed)
> 
> 
> 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
> 


=======================================================================
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)

[Steven Noels <st...@outerthought.org>]

Nicola wrote:

> 
> I'm happy that we found this solution: from a problem we created an
> opportunity, and this is good :-)
> 

Yes indeed.

Nice work, guys!

</Steven>

---------------------------------------------------------------------
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)

[Nicola Ken Barozzi <ni...@apache.org>]

From: "Morrison, John" <Jo...@uk.experian.com>

> Seperate the contrib/optional stuff from core?
>   Nicola: it looks like everyone (so far ;) is in favour of
> seperating this. I know you were/are looking at doing it; how
> far have you got?

I'm halfway through the samples, but haven't moved any class yet.
IMO, we can have four dirs: src/, src/scratchpad, src/optional and
src/contrib.
Each one of them creates a separate jar in the build, like scratchpad does
now.

The optional and contrib components must follow a precise rule: keep the
samples in a separate sitemap each, and have a .xoptional entry  (or
whatever, we can enhance-change the implementation at will) to specify the
libs-resources it needs.

When we are done with the Blocks thread and implementation, we can make this
deployment method used instead.

Is this ok?

> Should it be located in a seperate cvs?
>   Enough -1's.  It stays in the current cvs.  If there's
> enough cause in the future, this can be rethought.

Yup. Makes sense.

> Now, back to the POI problem... :)

:-)

Ok, my opinion is that it can go in a contrib dir, as described above
Now that a consensus has been reached, I'll go in this direction as fast as
possible, hopefully to be finished by the end of this week.

I'm happy that we found this solution: from a problem we created an
opportunity, and this is good :-)

--
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