jakarta-taglibs-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Turner <j...@socialchange.net.au>
Subject Re: resubmit: build process without .bat and .sh files
Date Sat, 05 May 2001 16:26:19 GMT

This is one of the neatest build systems I've ever seen. Clean, simple.. way
that projects can "hook" into the generic build process with pre and
post-targets is just beautiful :)

Enough with being nice ;) I had a good play, and have a few questions..

On Wed, May 02, 2001 at 06:51:50AM -0500, Tim Dawson wrote:
> I sent this out a week and a half ago, hoping for some feedback. I'd very
> much like to see the current build process improved, to get rid of the .bat
> and .sh scripts, and to remove the way the build system forces you to have
> certain jar files installed in certain places without clear directions or
> error messages.
[..]
> I know I was planning to send this out weeks ago, but life got in the way.
> The usual excuses. :-)
> 
> One problem with the current build system that I've tried to solve is the
> confusion surrounding getting your environment set up set up to build the
> taglibs -- if you just download and try to install, it just won't work, and
> you have to look through the build.bat, build.sh, and build.xml files to
> figure out why - not a great approach for newbies or people who just don't
> have the time.  Other problems included inconsistencies between different
> taglib builds and the fact that necessary differences are hard to spot when
> the bulk of the xml file is the same as all the others.
> 
> ------------------------
> 
> GOAL1: eliminate the .bat and .sh scripts
> 
> To solve #1, I had to replace the two major pieces of functionality within
> the .bat and .sh scripts: (1) extract environment variables and pass them
> into java, and (2) ensure that Xalan and Xerces are in the Ant runtime so
> that the <style> tags in the documentation target will run.

1) Would it be possible/desirable to eliminate environment variables
altogether, and just require the user to edit a properties file (with entries
like "servlet.jar=/var/tomcat/lib/servlet.jar")?

Environment variables have the disadvantages that:
 - they're ephemeral, lost when the terminal/DOS box closes (unless stored in
   .bash_profile, etc)
 - the notion of an environment variable isn't portable across OSes

Env variables -> properties would be a trivial change in common.xml.


2) For Xerces, a grep indicates that there are no direct dependencies in the
source. Recent version of Ant come with crimson.jar instead of xerces.jar.
Crimson is functionally identical, so why insist on Xerces?

3) For Xalan, the class looked for (org.apache.xalan.xslt.Stylesheet) does not
exist in recent versions of Xalan. However, this vintage of xalan is
*required* for the xsl taglib. The only jar I could find was xalan_1_2_2.jar
from Cocoon. When I put this in my ANT_HOME/lib, Ant died, with the following
error:

BUILD FAILED

/home/jeff/apache/jakarta/jakarta-taglibs/application/build.xml:91: javax.xml.transform.TransformerFactoryConfigurationError:
java.lang.ClassNotFoundException: org.apache.xalan.processor.TransformerFactoryImpl
--- Nested Exception ---
javax.xml.transform.TransformerFactoryConfigurationError: java.lang.ClassNotFoundException:
org.apache.xalan.processor.TransformerFactoryImpl
        at javax.xml.transform.TransformerFactory.newInstance(TransformerFactory.java:121)
        at org.apache.tools.ant.taskdefs.optional.TraXLiaison.<init>(TraXLiaison.java:87)


This is because later versions of Ant (I'm using 1.4a) default to a
TraX-compliant processor, which xalan_1_2_2.jar isn't. No, this can't be fixed
with the "processor" attribute. The solution is to have *both* versions of
xalan.jar in the classpath or $ANT_HOME/lib directory.

Overall, I've come to think that it isn't the job of a project build.xml to
enforce the existence of jars which core Ant tasks require. I want to be able
to use *any* JAXP-compliant parser, not just Xalan (whichever version).
Likewise with xerces/crimson -- it's not common.xml's job to enforce which I
use. In fact it *cannot* do so reliably, as the above problems illustrate.

So I say remove the Xerces and Xalans checks from common.xml totally. Because
xalan1.2.2 is directly required by the xsl taglib, the check currently in
common.xml can be moved to a "checkRequirements.pre" target in the xsl's
build.xml.


There, I've had my rant.. just one more point :)

When building the documentation, I get this warning:

documentation:

default.pre:
     [copy] Copying 1 file to /home/jeff/apache/jakarta/build/taglibs/application-doc/WEB-INF
    [style] DEPRECATED - the style attribute should be relative to the project's
    [style]              basedir, not the tasks's basedir.
    [style] Transforming into /home/jeff/apache/jakarta/build/taglibs/application-doc
..

This is because I'm using bleeding-edge Ant. After a bit of digging, I
unearthed the thinking behind this here:
http://marc.theaimsgroup.com/?t=98477438800011&w=2&r=1

It's simple enough to fix this in common.properties:

20c20
< taglibs.xsl = ../../../src/doc/stylesheets/taglibs.xsl
---
> taglibs.xsl = ${basedir}/../src/doc/stylesheets/taglibs.xsl


Anyway, this "fix the build process" thread has been kicking around for ages.
I hope this excellent system finally gets implemented.

--Jeff

> 
> Tim Dawson
> Chief Software Architect
> WAM!NET, Inc.



Mime
View raw message