From burton@relativity.yi.org Fri Mar 3 23:52:17 2000
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 16622 invoked from network); 3 Mar 2000 23:52:17 -0000
Received: from universe.kendara.com (HELO localhost.localdomain) (131.161.52.92)
by locus.apache.org with SMTP; 3 Mar 2000 23:52:17 -0000
Received: from relativity.yi.org (IDENT:root@localhost.localdomain [127.0.0.1])
by localhost.localdomain (8.9.3/8.9.3) with ESMTP id RAA21488
for ; Fri, 3 Mar 2000 17:52:16 -0800
Sender: root@localhost.localdomain
Message-ID: <38C06C50.32BA7C9E@relativity.yi.org>
Date: Fri, 03 Mar 2000 17:52:16 -0800
From: "Kevin A. Burton"
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.12-20 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: ant-dev@jakarta.apache.org
Subject: Re: XSL taskdef (vote to include)
References: <85256897.007273B0.00@d54mta04.raleigh.ibm.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Spam-Rating: locus.apache.org 1.6.2 0/1000/N
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 :)
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."