ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rajiv Mordani <>
Subject Re: XSL taskdef (vote to include)
Date Sat, 04 Mar 2000 01:21:41 GMT
Kevin A. Burton wrote:
> 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:
> > >
> > > <xsl in="in.xml" xsl="in.xsl" out="out.xml"/>
> > 
> > +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 <xsl> tag you won't need the xalan.jar but
> > > 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 <available> 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 <xsl> 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 

- Rajiv


> Kevin
> -- 
> Kevin A Burton (
> 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.

View raw message