Hi Tim

I've integrated your build changes into the IO tag library which is now in
CVS. I liked the changes alot! It makes things *much* easier. Well done Tim,
I think this is great work.

In summary, provided someone sets up Ant with xerces & xalan in the
ANT_HOME/lib and adds the servlet.jar to their classpath they can just run
the regular ant build. Cool.

I checked in the common.xml and common.properties into the jakarta-taglibs
directory and the IO build.xml file now references them (so its tiny now,
hooray!).

I made a couple of minor patches:-

* added an optional gen-docs target to generate the HTML and TLD from an XML
document in the xml subdirectory of a project. Basicallly this is the
taglib-doc-kit stuff. I browsed many of the existing taglibs in CVS and
couldn't find any explicitly using the taglib-doc kit. Do people do this
locally by hand?
I've added the gen-docs to the normal build for the IO library, so the TLD &
HTML will always be up to date.

* removed classpath="${classpath}" attribute from the <javadoc> build task.
I've not got to the bottom of this yet (I had a similar problem with
Jakarta-Commons) but on Win2000, JDK 1.3 and Ant 1.3 the explicit classpath
attribute breaks javadoc. Seems to work fine without it.

* commented out the 3 checks for SERVLET_JAR envirnment variable, xalan &
xerces. Firstly I'd rather just have the servlet.jar in my classpath (or in
ANT_HOME/lib) so was going to get around to changing this test to be class
based, rather than environment variable based. Secondly, for some reason,
even though I had xerces & xalan in my ANT_HOME/lib directory, the checks
failed. Commenting out these 3 checks and the build works perfectly ;-)


I really like this new build process. Hopefully if a user can get one taglib
building with the new process then they all should work. The only down side
I've noticed so far is that if an error occurs in a build, the line number
of the build.xml is wrong (because its doing a logical #include of
common.xml inside build.xml so the line numbers are wrong). This is a shame,
I find the line number in the build.xml a useful way of quickly finding out
which task failed and why.

I'm about to start using the same build process on the xtags library too.

At some point I'd like to modify the common build process to add a
'developer' build target such that the examples web apps can built in the
same place as the JSP. e.g. if you have

    examples/web/foo.jsp

then the web app WEB-INF would be created in place...

    examples/web/WEB-INF

Then you can edit your JSP and hit reload on your browser without doing a
full Ant build each time.

James

Reply via email to