As someone who is actually using jspc ...
> - 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). -1 I actually need real java classes, with a package name I can customize and deployed in an arbitrary directory (outside tomcat tree). > 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). Not sure which 'webapp mode', but generating the web.xml fragment is an essential feature and 100% standard - it translates JSPs to servlets and generates the web.xml declarations. After the operation you'll have very servlets in a standard web.xml. As for jasper runtime - it can be included in the webapp ( just like any library ). AFAIK the runtime doesn't depend on tomcat. > - Precompilation should only occur at webapp deployment time in the > general case (the generated code is closely tied to the Jasper runtime > release). I need precompilation at build time - the distributed .war will have only servlets. > - 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). Again, I must -1 this too. > > <ballot> > +1 [ ] Remove the options > -1 [X] Do not remove the options > </ballot> I agree jspc needs some refactoring - and only the 'webapp' mode should be preserved, but I think my use case is valid and should be preserved. At the moment I only use jasper inside ant - so removing the CLI completely, removing the javac compilation and so on would be fine ( for me ). Costin -- To unsubscribe, e-mail: <mailto:tomcat-dev-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:tomcat-dev-help@;jakarta.apache.org>
