jakarta-taglibs-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Dawson <tdaw...@wamnet.com>
Subject build process without .bat and .sh files
Date Fri, 20 Apr 2001 12:42:13 GMT
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) was easy because Ant 1.3 now supports grabbing environment variables.
(2) was a little tougher, and while I'm not entirely happy with the approach
I've resorted to, I can't think of anything better.  The main problem is
that I didn't see any way to modify the ant runtime once it was started I
couldn't figure out any good way to get around this, except to force the
user to install xalan.jar and xerces.jar to their ANT_HOME/lib directory, so
that they're included by default. The only real improvement I was able to
make was to add a couple of good fail messages to explain to the person what
they needed to do.

Result: the taglib-specific .bat and .sh scripts can be removed, and you
just use the standard scripts provided by Ant to run Ant.


GOAL2: remove the hardcoded locations for external jars such as servlet.jar
and oro

This is where I've made use of environment variables and a few good error
messages. Luckily, not very many of the taglibs require external jars, so
the number of environment vars to set is minimal.


GOAL3: improve error messages when build environment is not configured

And the system does a good job of prompting you for why it can't compile if
something is missing. There are a number of long <fail> calls in xml build


GOAL4: eliminate inconsistencies between taglibs

I created a common.xml file that is imported via standard XML import.  Most
subprojects simply define their project name (and hence the taglib name) and
then import the common.xml file.


GOAL5: allowing necessary differences between taglibs

Most targets call "pre" and "post" targets.  I used properties to define all
the pre and post targets to "default.pre" and "default.post", which do
nothing. But a taglib can provide a pre- or post- target before including
the common.xml, and it will get called. See the bsf build.xml file for an

Attached are four files: common.xml is included by each taglib's build.xml.
common.properties is read by common.xml.  both of these go in the main
jakarta-taglibs directory. application.build.xml should be copied into
jakarta-taglibs/application/build.xml, and provides an example of the
"simple" taglib.  bsf.build.xml should be copied into
jakarta-taglibs/bsf/build.xml and provides an example of a more complex
taglib that provides custom behavior.

I don't expect this will be adopted verbatim, but I think it's a good start.
Please review and share your comments...

Tim Dawson
Chief Software Architect

View raw message