You are viewing a plain text version of this content. The canonical link for it is here.
Posted to taglibs-dev@jakarta.apache.org by Tim Dawson <td...@wamnet.com> on 2001/05/02 13:51:50 UTC

resubmit: build process without .bat and .sh files

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.

Pierre Delisle has promised to take a look at it when he gets a breather
from preparing JSR-052 for JavaOne, but I'm resending this in hopes that
other people will also take a look and provide feedback.

Thanks,

Tim

--

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
correctly

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

------------------------

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

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
WAM!NET, Inc.



 <<common.xml>>  <<common.properties>>  <<application.build.xml>>  
<<bsf.build.xml>> 

Re: resubmit: build process without .bat and .sh files

Posted by James Strachan <ja...@yahoo.co.uk>.
Hi Tim

From: "Tim Dawson" <td...@wamnet.com>

> but I'm resending this in hopes that
> other people will also take a look and provide feedback.

First of all - deepest appologies. Pierre mentioned 'Ted's build process
changes" recently on this list and I kept referring to 'Ted's work when all
the time it was yours instead. Sorry about that Tim.

I'll be looking closely at your build stuff today and tomorrow - I'm getting
IO, logging and xtags ready for addition to CVS so I'll try use your build
process as much closely as possible.

One quick comment before I go into your proposal in detail. I've been using
the /example/web directory as the destination of the build for the
"examples" Ant target. i.e. I make a directory /examples/web/WEB-INF as part
of the build and copy the web.xml and TLDs in there.

This means as a developer you can just edit the example JSP and hit reload
on your browser and hey-ho you're ready to go. No ant build process required
when editing JSP. RAD development and all that. Its just an optimisation
that helps developers work quicker. It might be nice to adopt this technique
across taglibs.

Anyways, more later when I've gone into your proposal in detail.

James


_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com