(note: I'm bringing this discussion back to just taglibs-dev, since
taglibs-user is probably just interested in getting libraries pre-built)
> Tim Dawson wrote:
> > I'd be happy to do the revisions to the build.xml files, but
> > I'll have to mail it to someone with checkin capability.
> > I'd probably update
> > one and send it out to see if people agreed with the direction.
>
> This would be awesome. I'll be happy to review (as many
> others I'm sure). Please post to the list.
I originally planned just to modify one of the build.xml files, but to
validate my approach I ended up modifying all of the build.xml files and
removing all the build.sh and build.bat files. So it will probably make
sense for me to make all the mods and get them checked in rather than asking
each library owner to redo all the mods I've already made. (assuming the
approach described below is approved)
I'm not quite done with all the mods yet, but I thought I'd send out a
couple of examples to spark discussion and make sure that the direction I'm
headed in is acceptable...
What I did is this:
---
(1) created a shared build.properties file (attached) that resides in the
jakarta-taglibs main directory that defines all the properties used by the
build.xml files. the build.xml files all have a lot of duplication but seem
to follow the same paradigm. to make things simpler, I just pulled out all
the properties declarations into a separate file.
NOTE: I was a little uncomfortable with having a dependency on a shared
file (it would be nice if the distinct libs could be downloaded and built a
la carte), but then I realized that they all already depend on the shared
taglibs.xsl stylesheet, so I figured it might pass muster. :-)
(2) the taglib.name is now set identical to the project name (now available
in the predefined variable ${ant.project.name} in Ant 1.3) this allows
setting that property in the build.properties file. While I was putting
this in place I noticed a few taglibs didn't have their project name set
properly, so I updated those...
(3) Each build.xml file now has a checkRequiredComponents task which prepare
depends upon. The attached build.xml file comes from the BSF taglib, which
is a good example as it has an external dependency on the BSF jar either
being in the classpath or having an environment variable set.
NOTE: This is one area that needs consensus. a default installation is NOT
defined for each jar. This is for three reasons: it's a bit confusing,
(IMHO) probably rare that the jar would be in that location, and to top that
off, it wasn't *immediately obvious* how to implement it given our use of
environment vars. :-)
However, the system will build if (a) the required component jar is in
$(ANT_HOME)/lib, (b) the required component jar is found in $(CLASSPATH), or
(c) the required component jar is defined as an environment variable.
Failing that, the build will <fail> with an appropriate message.
---
Based on the approach above, it's pretty straightforward to build the
system, and if anything is missing, you're directed where to get it and how
to install it.
One thing I had intended to do with this was to allow defining environment
variables for xerces.jar and xalan.jar as with the other dependencies such
as log4j.jar or bsf.jar. Unfortunately, this didn't turn out to be feasible
since those are required for the <style> task inside the doucmentation
targets, and there is no (easy) wasy to add jars to the java runtime within
ANT. (it's probably possible by defining a new task name with the same class
name as the style task but giving it additional classpaths to run within,
but that's pretty hackish, and would dirty up all the build.xml files)
Another comment is that I don't particularly like the way the
checkRequiredComponents target works... the approach of using <available>
followed by <antcall> to a target that uses the unless attribute is about
the best I've come up with, but I'm going to propose an update for Ant 1.4
that allows an "unless" or "if" extension on <fail>, which would do away
with the extra target and <antcall>. We'll probably have to live with this
approach for now though, unless someone else can suggest a better
alternative.
Anyway, please review the approach above as well as the attached files and
post your comments. I'm interested to see what everyone thinks... if this
approach is approved, I'll go ahead and complete my updates to the rest of
the build.xml files (basically adding the checkRequiredComponents to all of
them and a side-job of updating DELTREE to DELETE and COPYFILE to COPY so we
don't get those deprecated task warnings anymore).
Tim
build.properties
build.xml
