On Friday 08 November 2002 03:28 pm, Hans Bergsten wrote: > Glenn Nielsen wrote: > > Remy Maucherat wrote: > > [...] > > I agree that JSPC needs to be simplified and that the webapp mode should > > be retained. But the webapp mode should allow for a war file to be > > generated > > which is self contained including the precompiled JSP classses. And for > > the > > generated war to be able to run from the war file with no need to unpack > > it. > > Why add this to JSPC? Isn't it already very easy to use external tools > to create the WAR file (the jar command, ant's war task, etc)? I have > no objections to cleaning up the JSPC code, but I would like it to > stay focused on it's its main task: convert JSP source to servlet > source. I have sometimes wished for automatic compilation of the servlet > source to class files, but in the name of simplicity and separation of > concerns, I think it's better handled by other tools. > In one way, it would be better to have the JSPC do the java compilation, because it can tell exactly what the environment is supposed to be. The libraries that are available, etc. It's reproduceable in ant, but it's not a terribly expensive option to maintain in jasper2, since it follows the same path as the runtime compiler.
> > Also I agree that this feature is a proprietary feature of Tomcat and we > > should no longer try to generate a war that can be deployed in any > > container. > > Why not? This works today (at least in TC 4.0.4) and I find it very > handy to be able to create a JAR file for all my JSPs that I know I > can deploy to any container along with the jasper-runtime.jar. If there > are issues with this that I don't know about, please tell me. Otherwise > I see no reason to remove this capability. > > If you can use JSPC to create the servlet source and web.xml fragments, > it's easy to use other tools to compile the source and create a WAR with > all other parts of the app (servlets, taglibs, web.xml, static stuff, > etc.) and deploy it to Tomcat or any other container. As far as I can > see, there's no need for a proprietary solution to get this to work. > > > [...] > > Hans -- To unsubscribe, e-mail: <mailto:tomcat-dev-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:tomcat-dev-help@;jakarta.apache.org>
