Re: [xml-dev] Even if you're not ... was If you're going to the W3C meeting in March

[Alan Gutierrez <alan-xml-dev@engrm.com>]

* Kurt Cagle <kurt.cagle@gmail.com> [2005-01-30 00:54]:

> >     I'd wanted to use XSLT in Ant for quite some time, since I
> >     started programming in Java in 2003. If I think about it, these
> >     where the blocks.
> > 
> >     1) Experience with Maven, which left me the with the impression
> >         that scripting in XML, in certian situations, was somehow
> >         inheriently foolish.
> > 
> >         Maven is a solution that uses an XML language to generate
> >         Ant.  It is complex and tempremental. It is difficult to
> >         read. If you know Ant, that knowledge is lost since your Ant
> >         is burried in another language, Jelly.
> > 
> >         Maybe it's because those are /my/ angle brackets, but my
> >         XSLT code is easy to read and it is easy to add a new task
> >         to all my projects.
> > 
> >     2) If it is such an obvious solution, and no one is doing it,
> >         then, there must be something wrong.

> I used the XSLT + ANT approach to good effect in the creation of
> workflows for an automated publishing system a few years back. The
> XSLT made it possible to templatize "filters" -- ANT scripts --
> for different customers, in effect providing a clean user
> interface for defining workflow blocks that could then be retained
> or modified if the customer wished to run new books for
> publishing. It's a VERY powerful approach, and something I would
> recommend far above trying to script such work directly.

    Indeed.

    I noted that I tried Maven, because it was all the rave as I was
    getting started in Java. Afterwards, I was all about pure Ant.
    That lead to some convuluted, illegable, Ant scripts.

    XSLT is very economic.

    But now I'm creating a large XSLT file with targets, like
    antlr or javacc, that re not needed in all projects.
    
    So, I'm trying to sort out a solution that is slightly
    pluggable, if only as an exercise, since a lack of modulatrity
    will prevent me from using XSLT in other projects.

> I've stayed away from Maven precisely for the reasons that you
> mentioned, something I've heard echoed elsewhere. My experience with
> DOM in general has been that it only really makes sense when the
> number of changes involved in working with an XML document are VERY
> small - and even there I often found that as I want to work with other
> pieces of data, I will inevitably reach a point where its simply
> easier to throw out the DOM code completely and rewrite it as
> parameterized transformations.

    DOM? Is Maven DOM based? I thought Maven was based on a language
    called Jelly.
    
    When I found out that I had no choice but to learn Jelly in
    order to alter the bootclasspath, I dumped Maven.

> I like your comment about "if there is no one else doing it, there
> must be something wrong with the approach". One of the things that
> I've come to realize over the years is that, at least as far as XSLT
> and related technologies is concerned, the reason that no one else is
> doing it is because there are only recently enough people in the field
> to even conceive that it was doable this way in the first place. In
> other words, I think that many people on this list especially tend to
> be pioneers, effectively the first to either approach a problem this
> way or at the minimum the first to publish these approaches in the
> literature. I think that the book on XSLT best practices has not yet
> been written (though Michael Kay comes close).

  ~ Recently, I offered to provide build scripts for an XML open
    source project. When they heard that the process would be.

        svn checkout http://foo.com/svn/foo
        cd foo
        ant -f mix.bootstrap.xml
        ant

    They rejected it for the third line. And Ant script /should/
    just work from checkout.

    But for any project of any real size, it doesn't.
    
    Generally, the checkout includes an endoresed ant and a pair of
    build.sh, build.bat files that set the system class path,
    because Ant classpath directives, for many tasks are defeated by
    the $ANT_HOME/lib directory.

    If you don't know what I'm talking about, you'll never
    understand why I get so huffy when someone uses the word
    /should/ in reference to Ant.

    In any case, this is part of why no one else is doing it. The
    notion that there should be an intermediate step is somehow
    anathama. Counter it you're mired in a "bicycle shed" discussion
    of what a build system /should/ be.

        svn checkout http://foo.com/svn/foo
        cd foo
        ./configure
        make

    That's no problem, I suppose.

    The developers won't be able to hack the build.xml file, they
    have an extra step, this will deter developers from participation.

    These are straw men, really. For many reasons, but the main
    reason is that one a build works, it works.
    
    The contributors shouldn't have to hack the Ant files constantly.
    They only have to now because they rely solely on Ant.

  ~ Another impediment to Ant + XSLT is the fact that XSLT, as
    provided by Ant, is ancient. If you want to use a newer
    implementation of Xalan, or Saxon, you have ClassLoader issues.

    The suggested solution is to copy the correct jar into your
    $ANT_HOME/lib. This makes for a drasitc alteration of your ant
    installation, one that is hard to proscribe.

    XSLT comes across as a problem child. It triggers all the Ant
    ClassLoader issues. Those issues are really Ant's issues, but
    XSLT is the one that suffers.

  ~ Somehow, denizens of Javaland see build configuration as a
    choice between pure Ant and Maven.
    
    I'm seeing this happen more often than not. One solution will
    somehow become a standard of sorts, in the case Maven, and
    people will wait for it, rather than pursue something similar.

    The XSLT + Ant approach is mentioned in the Ant in Anger essay,
    which in as old a Ant itself. Yet the configuration solution
    that became the new standard is based on, Jelly? Strange.

  ~ Acutally, in my formative experiences with XSLT, I didn't
    realize that it was a functional programming language.
    
    As my transforms became more and more complex, I kept expecting
    the XSLT engine to choke. Didn't happen.

--
Alan Gutierrez - alan@engrm.com