Return-Path: Delivered-To: apmail-jakarta-avalon-dev-archive@jakarta.apache.org Received: (qmail 24718 invoked by uid 500); 21 Sep 2001 05:01:37 -0000 Mailing-List: contact avalon-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Reply-To: "Avalon Development" Delivered-To: mailing list avalon-dev@jakarta.apache.org Received: (qmail 24707 invoked from network); 21 Sep 2001 05:01:36 -0000 Content-Type: text/plain; charset="iso-8859-1" From: Peter Donald To: "Avalon Development" Subject: Re: XML Components & Root Roles file Date: Fri, 21 Sep 2001 14:55:08 +1000 X-Mailer: KMail [version 1.3.1] References: <3BAA224B.AA7D06CE@apache.org> In-Reply-To: <3BAA224B.AA7D06CE@apache.org> X-Wisdom-Cookie: . MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <20010921050134.HWVL13193.mss.rdc2.nsw.optushome.com.au@there> X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N On Fri, 21 Sep 2001 03:07, Berin Loritsch wrote: > There are two things I would like to propose: > > Backporting the XML components from Cocoon. Specifically, I am > speaking of the XMLParser, XMLTransformer, Compiled XML support, > and introduction of the XPath component. This will allow us to > support the same solutions in multiple environments. The projects > this would benefit in addition to Cocoon would be Giacomo's > XML-Java utility, Axis, and any other XML based system. +1 for XPath but I am not sure about the other utilities. I was under the impression that the other utilities required classes/interfaces from the XML pipeline. If so wouldn't moving these to Avalon be like ripping out the heart of Cocoon? Not saying this is entirely a bad thing (I have wanted to use pipeline in another project) especially if the components are largely stable. However what do the Cocoon committers think of it? Would it be be better to package Cocoon into two parts - the pipeline and all general XML utilities - the Cocoon specific components (ie sitemap, the language components etc) This would still allow reuse by other projects but allow Cocoon to keep it's funky image/branding. Not sure. It would be great to have that stuff in Avalon but we don't want to steal Cocoons thunder ;) BTW on a somewhat related note I have got a few suggestions/requests or noticed people asking for things like the following. Basically one request was to make phoenix/cornerstone a separate project and another was to make excalibur packaging fine-grained. Re: Separating phoenix/cornerstone I don't mind as soon as Phoenix reaches beta but until then it sounds like too much work. If we ask PMC when we hit beta then we can open the new project with a bang. Re: Fine grain packaging of excalibur Sounds good but a LOT of work ;( One person recomended doing something like that which occured at Giant Java Tree (a servlet packages it for you on request). However I recall that was always broken and would prefer to do it with a new ant task. Something like

for every product we decide to bundle separately. Anyways both sound like work I don't have time todo atm ;) > Creating a master Roles file for Excalibur. This will enable > the same configuration elements to be used in the same manner > accross all Excalibur Component Manager users. Admittedly, there > will have to be some entries for when there is expected to only > be one DataSource in a system (like "jdbc-datasource"). +1 -- Cheers, Pete *------------------------------------------------------* | "Common sense is the collection of prejudices | | acquired by age 18. " -Albert Einstein | *------------------------------------------------------* --------------------------------------------------------------------- To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org For additional commands, e-mail: avalon-dev-help@jakarta.apache.org