Return-Path: Delivered-To: apmail-xml-cocoon-dev-archive@xml.apache.org Received: (qmail 77973 invoked by uid 500); 12 Mar 2002 13:48:23 -0000 Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: cocoon-dev@xml.apache.org Delivered-To: mailing list cocoon-dev@xml.apache.org Received: (qmail 77962 invoked from network); 12 Mar 2002 13:48:22 -0000 Message-ID: <003a01c1c9cc$31890820$670004c0@PC103> Reply-To: "Nicola Ken Barozzi" From: "Nicola Ken Barozzi" To: References: Subject: Re: [VOTE] Seperate Contrib/optional area/cvs (was: RE: POI Serialization code committed) Date: Tue, 12 Mar 2002 14:45:37 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N From: "Morrison, John" > 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