Re: [VOTE] Proposed jspc refactoring

[Costin Manolache]

To clarify - I agree jspc has a lot of broken options and
features. My use case is:

    <taskdef classname="org.apache.jasper.JspC" name="jasper2" >
      <classpath>
        <pathelement location="${java.home}/../lib/tools.jar"/>
        <fileset dir="${tomcat.home}/server/lib">
          <include name="*.jar"/>
        </fileset>
        <fileset dir="${tomcat.home}/common/lib">
          <include name="*.jar"/>
        </fileset>
        <pathelement location="${build.dir}/classes"/>
        <path refid="all_other_jars"/>
      </classpath>
    </taskdef>

    <jasper2 verbose="0"
             package="my.package"
             compile="true"
             validateXml="false"
             uriroot="${webapp.dir}"
             webXmlFragment="${build.dir}/generated_web.xml"
              outputDir="${build.dir}/src/my/package" />

    <loadfile property="generated_web.xml"
              srcFile="${build.dir}/generated_web.xml"  />

    <replace file="${jspui.webapp.dir}/WEB-INF/web.xml"
             token="&lt;!--GENERATED_JSPS--&gt;"
             value="${generated_web.xml}" />

   <javac destdir="${build.dir}/classes"
           optimize="off"
           debug="on"
           srcdir="${build.dir}/src" >
      <classpath refid='...' />
      <include name="my/package/**" />
    </javac>


Removing the CLI or any other options is fine for me. I don't need
jspc to compile or do any fancy thing - just compile JSPs to servlets
and generate the web.xml fragment.

Costin

Remy Maucherat wrote:

> Hi,
> 
> jspc is IMO overly complex, with many features nobody knows how to use,
> and nobody cares to test (hence sometimes some of them are randomly
> broken during Jasper refactorings).
> 
> I propose that:
> - In Tomcat 5, all jspc options are removed, in favor of allowing only
> the webapp mode (with its relevant options). This webapp mode would
> generate code and classes which should be deployed in the work
> directory, exactly the same as if they were dynamically compiled by
> Jasper (which has the big advantage of using only one big operation mode
> for everything). Single file mode is IMO useless (dynamic compilation
> works fine).
> - In Tomcat 4.1, the options will stay in for compatibility, but the
> usage help will be modified to be the same as Tomcat 5.
> 
> It has to be noted that:
> - The JSP runtime is now very efficient. The old webapp mode (with its
> static web.xml) is a hack (and a 100% proprietary one at that).
> - Precompilation should only occur at webapp deployment time in the
> general case (the generated code is closely tied to the Jasper runtime
> release).
> - Additional features could be added to the manager servlet to, for
> example, cause precompilation of the deployed webapp in a separate
> process. - I am -1 to returning to the old "webapp" option behavior (ie,
> the generated files should by default be deployed in the work directory,
> not /WEB-INF/classes).
> 
> <ballot>
> +1 [ ] Remove the options
> -1 [ ] Do not remove the options
> </ballot>
> 
> Note: Users may vote, but only committers have binding votes.
> 
> Remy




--
To unsubscribe, e-mail:   <mailto:tomcat-dev-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:tomcat-dev-help@;jakarta.apache.org>