Return-Path: Mailing-List: contact ant-dev-help@jakarta.apache.org; run by ezmlm Delivered-To: mailing list ant-dev@jakarta.apache.org Received: (qmail 84426 invoked from network); 4 Mar 2000 01:21:43 -0000 Received: from chinet.com (HELO chinet.chinet.com) (root@209.219.112.20) by locus.apache.org with SMTP; 4 Mar 2000 01:21:43 -0000 Received: (from mode@localhost) by chinet.chinet.com (8.9.3/8.9.3) id TAA15859 for ant-dev@jakarta.apache.org; Fri, 3 Mar 2000 19:21:42 -0600 From: Rajiv Mordani Message-Id: <200003040121.TAA15859@chinet.chinet.com> Subject: Re: XSL taskdef (vote to include) In-Reply-To: <38C06C50.32BA7C9E@relativity.yi.org> from "Kevin A. Burton" at "Mar 3, 2000 05:52:16 pm" To: ant-dev@jakarta.apache.org Date: Fri, 3 Mar 2000 19:21:41 -0600 (CST) X-Mailer: ELM [version 2.4ME+ PL60 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Rating: locus.apache.org 1.6.2 0/1000/N Kevin A. Burton wrote: > rubys@us.ibm.com wrote: > > > > Kevin Burton wrote: > > > What I propose is to create a new task that will transform an XML > > > document with a Stylesheet into another XML document: > > > > > > > > > > +1 > > Cool. > > > > I could include this as part of Alexandria but I think it belongs here. > > > The only downside is that it brings up the requirement of Xalan. As > > > long as you don't use the tag you won't need the xalan.jar but you > > > would need it to compile. > > > > I would prefer if this task were conditionally compiled. We are almost to > > the point where there are no jars checked into this project - and hopefully > > soon the last one will be removed. And considering that one can build > > xalan with ant, I can imagine that having a back level version of xalan in > > your path could cause confusion for developers on that project. > > > > In case you haven't kept up with the flood of discussion on this mailing > > list recently, there are at least two strategies for accomplishing > > conditional compilation. One is by having additional targets which copy > > java code into the directory that will later be the srcdir for a javac. > > Another is to add an nested exclude tag on the javac task itself. In > > either case, the steps can be made conditional on the presence or absense > > of a class in the classpath - see the task for more details. > > > > Note: you will also need to take care to ensure that the project can still > > bootstrap. This is perhaps best accomplished by placing this source in a > > separate directory. > > > > While this will likely be the first conditionally compiled taskdef, I do > > expect more to come shortly. > > Hm. I can appreciate that. I would however like to include the .jar. > I think that Xalan people will be smart enough to pick up on it. > > Also, I would like Xalan support compiled in by default. Xalan > developers should *not* use teh tag because this would be stupid. > Therefore although it was linked against the old Xalan it won't be a > problem. We should however mention this. > > On including .jar files... I really don't think this is a big problem. > I do not however like the project-x/javac stuff and I am glad that is > gone. However xalan is OSS and our own Dog Food so we should eat it :) Atleast compare 2 technologies that do the same thing... project X is an xml parser and xalan is an xsl engine.. On a separate note could you explain why you don't like project X. It is also going to be "OSS and our own Dog Food" soon. Would your opinion change then??? - Rajiv - > > Kevin > > -- > Kevin A Burton (burton@apache.org) > http://relativity.yi.org > Message to SUN: "Open Source Java!" > "For evil to win is for good men to do nothing." > -- UNIX _is_ user friendly, he's just very picky about who his friends are.