Remy has a point - the current code is not very clean, and doesn't seem to be tested/maintained enough.
I use the ant tasks - and I have a feeling many other users of jspc are doing the same. Removing the CLI and keeping the basic functionality seems like a good idea. For example compiling a jsp page outside a webapp can't work in all cases - if it has includes, etc it needs to resolve, it needs taglib definitions from WEB-INF, etc. I can't see any good reason to keep it if it's half broken by definition. Also - compiling the java files is the job of <javac>, and the mapping and web.xml fragment generation can be more easily done using only the ant tasks. I would go even further - since we are already using ant to compile the java to .class, it may be a good idea to make the .jsp->.java task 'first class'. In any case - the task is supported ( at least by me, it seems Henri is using it as well ). If there are people who want to support the CLI and the other options - then we can keep them, but if not - I think it's better to remove them or mark as unsupported. Costin Hans Bergsten wrote: > 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 will not formally vote on this, because I've been inactive in this > project for so long I feel I need to familiarize myself with the > current code base before I can exercise my voting priviledges. But I > do have some comments, see below. > >> 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). > > I agree with you regading single file mode, but not with the rest. > >> - 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. > > I'm not sure what you mean by this proposal. Are you saying that the > TC 4.1.x version would have a usage message (documentation) that doesn't > match its features? If so, why? If there will be differences between the > TC 4.1.x and TC 5 versions, I assume we will maintain a separate code > base for each version, each with documentation that correctly reflects > their features. > >> 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). > > Efficiency is not all that important here, since precomiplation is > done before deployment (that's the whole idea, right ;-) > > Not sure what you mean with "100% proprietary". The web.xml file (or > fragment) that is generated is defined by the servlet spec. > >> - Precompilation should only occur at webapp deployment time in the >> general case (the generated code is closely tied to the Jasper runtime >> release). > > I don't agree. It's very handy to be able to generate a JAR file with > all JSP pages for an application and deploy it to many different > container instances (Tomcat or others, as long as jasper-runtime.jar > is included). There are many users that want to keep the production > environment as simple (and small in embedded systems, for instance) as > possible, and deploying precompiled JSP pages lets me use a production > environment without the JSP compiler and use JRE instead of the JDK. > >> - Additional features could be added to the manager servlet to, for >> example, cause precompilation of the deployed webapp in a separate >> process. > > That's a separate thing, more of a container feature than JSPC in my > mind. > >> - 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). > > Why not discuss what the problems with the current options are, and > try to find a solution instead? Like I've said, it's been a while since > I was actively involved with Tomcat development, but I know that in > Tomcat 4.0.4, JSPC seemed to work fine with all options available at > the time. How did Jasper2 break things? If I understand what the main > problem is, I can help find a solution (primarily for Tomcat 4.1.x; I'm > afraid I don't have enough cycles to get into Tomcat 5 at the moment). > > Hans -- To unsubscribe, e-mail: <mailto:tomcat-dev-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:tomcat-dev-help@;jakarta.apache.org>
