Stefan Bodewig wrote:
Buts its key weaknesses are -does not (yet) do dependency based invocation. -doesnt use any javac choice (a feature of the jasperc library which I dont want to look at)
I think both are important features - depending on the number of JSPs of course. Users will also want that the chosen javac is the same the <javac> task would use.
I'm not sure I follow what you guys are talking about here. What do you mean by dependency based invocation? What has javac got to do with anything?
One issue to worry about first: what use cases are we addressing
with this task
1. compilation of jsp pages purely as a syntax checker before bothering to deploy
2. precompilation of jsp pages into java files /.class files for inclusion in war files
For me, I definitely need this task for 2, and that is what my implementation does (We are not allowed to have things like javac/tools.jar on our production machines). I am simply running org.apache.jasper.JspC on the given fileset. I took the code from javac, added in a package="" attribute to pass to JspC and use that to calculate the generated .java file name from the fileset of jsp files. I only use the basename of the jsp file combined with the package name to get the generated file name and then do dependency checking based on that mapping to decide what to build.
I run javac seperately. I have a seperate tree next to classes, usually called gensrc (I also use javacc and others) that these file go into and then run javac on both my source and generated source trees:
<jspc srcdir="${src.dir}/war"
destdir="${gensrc}"
package="com.i3sp.sso.jsp"
verbose="9">
<include name="**/*.jsp" />
</jspc>
<javac srcdir="${src.dir};${gensrc}"
destdir="${classes}"
debug="on"
optimize="off"
deprecation="on"
>
<include name="com/i3sp/**/*.java"/>
<exclude name="RegisterClient.java"/>
</javac>
I'm off to the snow for a week! Matt
