Re: XSL taskdef (vote to include)

[ru...@us.ibm.com]

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

> 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 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 <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.

- Sam Ruby

Re: XSL taskdef (vote to include)

[James Duncan Davidson <ja...@eng.sun.com>]

> 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 :)

But we don't need to permanently ingest it into the source tree. If you want
to build Xalan into Ant and we end up with the conditional compilation
stuff, then simply make the requirement that xml-xalan be checked out
parallel to jakarta-ant. No biggie. And no requirement for checking in jars
to get outdated into the source tree.

.duncan

Re: XSL taskdef (vote to include)

["Kevin A. Burton" <bu...@relativity.yi.org>]

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:
> >
> > <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 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 <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 :)

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."