youys
/
ant
Not watched
1
0
Fork 1
Code
Releases 0 Wiki Activity
Issues 0 Pull Requests 0 Datasets Model Cloudbrain
Browse Source

Clearly mark jspc task as deprecated

master
Gintas Grigelionis 7 years ago
parent
f2722e4079
commit
e0affbaa7c
2 changed files with 57 additions and 54 deletions
Split View
Diff Options
Show Stats Download Patch File Download Diff File
  1. +56
    -53
      manual/Tasks/jspc.html
  2. +1
    -1
      manual/tasklist.html

+ 56
- 53
manual/Tasks/jspc.html View File

@@ -25,31 +25,34 @@
<body>

<h2><a name="jspc">jspc (deprecated)</a></h2>
<h3><i>Deprecated</i></h3>
<p>
<i>If you use this task with Tomcat's Jasper JSP compiler, you should seriously
consider using the task shipping with Tomcat instead.</i> This task is only
tested against Tomcat 4.x. There are known problems with Tomcat 5.x that won't
get fixed in Ant, please use Tomcat's jspc task instead.<br/>
Instead of relying on container specific JSP-compilers we suggest deploying the
raw files (*.jsp) and use the container build-in functions: after deploying run
a test suite
(e.g. with <a href="http://attic.apache.org/projects/jakarta-cactus.html">Cactus</a>
or <a href="http://httpunit.sourceforge.net/">HttpUnit</a>) against the deployed
web application. So you'll get the test result <i>and</i> the compiled JSPs.
</p>
<h3>Description</h3>

<p> Apache Ant task to run the JSP compiler and turn JSP pages into Java source.

<p><b>Deprecated</b> if you use this task with Tomcat's Jasper JSP
compiler, you should seriously consider using the task shipping with
Tomcat instead. This task is only tested against Tomcat 4.x. There
are known problems with Tomcat 5.x that won't get fixed in Ant, please
use Tomcat's jspc task instead.<br/>
Instead of relying on container specific JSP-compilers we suggest deploying
the raw files (*.jsp) and use the container build-in functions: after deploying run
a test suite (e.g. with <a href="http://attic.apache.org/projects/jakarta-cactus.html">Cactus</a> or
<a href="http://httpunit.sourceforge.net/">HttpUnit</a>) against the deployed web
application. So you'll get the test result <i>and</i> the compiled JSPs.
<p>
Apache Ant task to run the JSP compiler and turn JSP pages into Java source.
</p>

<p>
This task can be used to precompile JSP pages for fast initial invocation
of JSP pages, deployment on a server without the full JDK installed,
or simply to syntax check the pages without deploying them.
In most cases, a javac task is usually the next stage in the build process.
The task does basic dependency checking to prevent unnecessary recompilation -this
checking compares source and destination timestamps, and does not factor
in class or taglib dependencies, or <code>&lt;jsp:include&gt;</code> references.
This task can be used to precompile JSP pages for fast initial invocation of JSP
pages, deployment on a server without the full JDK installed, or simply to
syntax check the pages without deploying them. In most cases, a javac task is
usually the next stage in the build process. The task does basic dependency
checking to prevent unnecessary recompilation - this checking compares source
and destination timestamps, and does not factor in class or taglib dependencies,
or <code>&lt;jsp:include&gt;</code> references.
</p>

<p>
By default the task uses the Jasper JSP compiler. This
@@ -60,23 +63,22 @@ and any other Jar files which may be needed in future versions (it changes)

We recommend (in March 2003) Tomcat version 4.1.x for the most robust version
of Jasper.
</p>

<p>
There are many limitations with this task which partially stem from the
many versions of Jasper, others from implementation 'issues' in the task
(i.e. nobody's willingness to radically change large bits of it to work
around jasper). Because of this and the fact that JSP pages do not have
to be portable across implementations -or versions of implementations-
this task is better used for validating JSP pages before deployment,
rather than precompiling them. For that, just deploy and run your httpunit
junit tests after deployment to compile and test your pages, all in one
go.
There are many limitations with this task which partially stem from the many
versions of Jasper, others from implementation 'issues' in the task
(i.e. nobody's willingness to radically change large bits of it to work around
jasper). Because of this and the fact that JSP pages do not have to be portable
across implementations -or versions of implementations- this task is better used
for validating JSP pages before deployment, rather than precompiling them. For
that, just deploy and run your httpunit junit tests after deployment to compile
and test your pages, all in one go.
</p>


<h3>Parameters</h3>
The Task has the following attributes:<p>
<p>The Task has the following attributes:</p>

<table border="1" cellpadding="2" cellspacing="0">
<tr>
@@ -178,52 +180,53 @@ The Task has the following attributes:<p>
<td valign="top">webinc</td>
<td valign="top">Output file name for the fraction of web.xml that lists servlets.</td>
<td valign="top" align="center">No</td>
</tr>
</tr>
<tr>
<td valign="top">webxml</td>
<td valign="top">File name for web.xml to be generated</td>
<td valign="top" align="center">No</td>
</tr>

</table>
</tr>
</table>

<P>The <tt>mapped</tt> option will, if set to true, split the JSP text content into a
<p>The <tt>mapped</tt> option will, if set to true, split the JSP text content into a
one line per call format. There are comments above and below the mapped
write calls to localize where in the JSP file each line of text comes
from. This can lead to a minor performance degradation (but it is bound
by a linear complexity). Without this options all adjacent writes are
concatenated into a single write.</P>
concatenated into a single write.</p>

<P>The <tt>ieplugin</tt> option is used by the <tt>&lt;jsp:plugin&gt;</tt> tags.
<p>The <tt>ieplugin</tt> option is used by the <tt>&lt;jsp:plugin&gt;</tt> tags.
If the Java Plug-in COM Class-ID you want to use changes then it can be
specified here. This should not need to be altered.</P>
specified here. This should not need to be altered.</p>

<P><tt>uriroot</tt> specifies the root of the web
<p><tt>uriroot</tt> specifies the root of the web
application. This is where all absolute uris will be resolved from.
If it is not specified then the first JSP page will be used to derive
it. To derive it each parent directory of the first JSP page is
searched for a <tt>WEB-INF</tt> directory, and the directory closest to
the JSP page that has one will be used. If none can be found then the
directory Jasperc was called from will be used. This only affects pages
translated from an explicitly declared JSP file -including references
to taglibs</P>
translated from an explicitly declared JSP file - including references
to taglibs</p>

<P><tt>uribase</tt> is used to establish the uri context of
<p><tt>uribase</tt> is used to establish the uri context of
relative URI references in the JSP pages. If it does not exist then it
is derived from the location of the file relative to the declared or
derived value of <tt>uriroot</tt>. This only affects pages
translated from an explicitly declared JSP file.</P>
translated from an explicitly declared JSP file.</p>

<h3>Parameters specified as nested elements</h3>

<p>
This task is a <a href="../dirtasks.html">directory based task</a>, like
<strong>javac</strong>, so the jsp files to be compiled are located as java
files are by <strong>javac</strong>. That is, elements such as <tt>includes</tt> and
<tt>excludes</tt> can be used directly inside the task declaration.
</p>

<p>
Elements specific to the jspc task are:-
Elements specific to the jspc task are:
</p>

<h4>classpath</h4>

@@ -231,9 +234,11 @@ The classpath used to compile the JSP pages, specified as for any other
classpath.

<h4>classpathref</h4>

a reference to an existing classpath

<h4>webapp</h4>

Instructions to jasper to build an entire web application.
The base directory must have a WEB-INF subdirectory beneath it.
When used, the task hands off all dependency checking to the compiler.
@@ -283,10 +288,11 @@ package hierarchy beginning with com.i3sp.jsp.
</pre>
Generate jsp pages then javac them down to
bytecodes. Include lib/taglib jar in the java compilation.
Dependency checking is used to scrub the
Dependency checking is used to scrub the
java files if class dependencies indicate it is needed.

<p><h4>Notes</h4>
<h4>Notes</h4>
<p>
Using the <code>package</code> attribute it is possible to identify the resulting
java files and thus do full dependency checking - this task should only rebuild
java files if their jsp file has been modified. However, this only works
@@ -295,14 +301,11 @@ with the "jasper" compiler, set the compiler to "jasper41" for the tomcat4.1.x
dependency checking.
Even when it does work, changes in
.TLD imports or in compile time includes do not get picked up.
</p>
<p>
Jasper generates JSP pages against the JSP1.2 specification -a copy of
version 2.3 of the servlet specification is needed on the classpath to
compile the Java code.



</p>
</body>
</html>


+ 1
- 1
manual/tasklist.html View File

@@ -109,7 +109,7 @@
<li><a href="Tasks/jjdoc.html">JJDoc</a></li>
<li><a href="Tasks/jjtree.html">JJTree</a></li>
<li><a href="Tasks/jlink.html"><i>Jlink</i></a></li>
<li><a href="Tasks/jspc.html">JspC</a></li>
<li><a href="Tasks/jspc.html"><i>JspC</i></a></li>
<li><a href="Tasks/junit.html">JUnit</a></li>
<li><a href="Tasks/junitreport.html">JUnitReport</a></li>
<li><a href="Tasks/length.html">Length</a><br/></li>


Write Preview
Loading…
Cancel
Save