> This is great! No more scripts to maintain, and very clean build.xml
> and build.properties. Thanks for doing it.
>
> A question for an ant guru. Are there any thoughts given in
> ant so that the
> same principle could be applied to build.xml?
Craig McClanahan's suggestion looks like it will help with this... but... I
think we should walk before we run. :-)
I'll get this much working so we can remove the build.bat and build.sh
files, once that's checked in and working for everyone, then I'll go back
and see if we can remove (or at least greatly simplify) build.xml too.
> > 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?
actually, this pertains to your next question as well. I've perhaps
oversimplified the problem...
there are three kinds of dependencies... ant runtime, java compile, and
example include dependencies.
* ant runtime
this is found in all all tasks require xalan.jar and xerces.jar to perform
the documentation XSL transform.
for this kind of dependency, environment variables won't help -- you have to
put the jars in the system classpath or in ant.home/lib (which is
automatically added to the system classpath)
* java compile
the BSF taglib requires that the bsf.jar be in one of the three places
mentioned so that the javac task will not fail (other taglibs such as regexp
do this as well)
in this case, the system classpath, ant.home/lib, or environment variable
will work.
* example include
the XSL taglib copies the xerces.jar and xalan.jar (and servlet.jar for that
matter) into its examples WEB-INF/lib directory. this won't be necessary in
servlet 2.3, since the WAR manifest can specify required external libs. (see
section 9.6.1 of the servlet 2.3 spec)
in this case, the environment variable must be specified, so we know where
to look for the jar to copy.
of course, the bsf taglib doesn't do the copy, while the xsl taglib does...
this is inconsistent. we should probably decide what's the best approach. to
copy? or not to copy and just document the dependency in the tld files...
> > 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.
I can see why that would be confusing, since the property was there for the
xsl taglib's build.xml, which I didn't include. :-)
I should also
> Also, does ant and the <style> tag really need xerces/xalan,
> or is jaxp compliance sufficient?
I don't think its the style tag itself that requires xerces/xalan, at least
the ant 1.3 installation doc doesn't list the style tag as having any
external dependencies. I think its our stylesheet & its use of
namespaces... but I'm not an XSL expert. Can someone else weigh in on this?
> Looks really good. My +1 is ready whenever you want to submit
> a vote...
glad to hear it! given the relatively slow rate of activity on this mailing
list, I'll give it a few more days to let others weigh in before moving
forward. If I don't hear anything by the end of the week that requires a
change, I'll spruce up the documentation messages a bit and update the other
taglibs over the weekend, then submit the whole set for a vote early next
week.
Tim
