Tim,
This is great! No more scripts to maintain, and very clean build.xml
and build.properties. Thanks for doing it.
A few comments/questions below.
-- Pierre
Tim Dawson wrote:
>
> (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)
Agree.
>
> 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. :-)
Anything to simplify the 'build' files each taglib has to maintain is good.
A question for an ant guru. Are there any thoughts given in ant so that the
same principle could be applied to build.xml?
Let me explain. As you mention, there will be a lot of duplication in the
build.xml in each taglib. Just like there is
<property file="../build.properties">
it would be great if there was something like:
<build file="../build.xml">
which would act as the "super-build" (as an analogy to superclass) of the
current build.xml. By default, the "sub-build" targets would be used, unless
they were overridden by the 'sub-build'.
With something like this, what would need to be in each taglib "buil.xml"
would be really minimal. Just a thought...
> (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. :-)
Personally, I've never relied on those default installation settings.
If this is important to anyone, please speak up...
>
> 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.
Is a, b, c, the order of precedence? Isn't env var first?
> ---
>
> 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)
I'm confused here. There is a xerces.jar and xalan.jar in the build.xml set
from environment variables.
Also, does ant and the <style> tag really need xerces/xalan, or is jaxp
compliance sufficient?
>
> 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.
It is fine as is, but I agree with you that an extension to <fail>
would be nice.
>
> 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).
Looks really good. My +1 is ready whenever you want to submit a vote...
