I have to time to go through and fix all the options (including cleaning up the code) but I would like to see what options are actually used (or would like to be used if they work)
I also have no problems maintaining jscp as I use it a lot and have customized it to do what I want. I would just like some direction to go with.. John > -----Original Message----- > From: news [mailto:news@;main.gmane.org] On Behalf Of Costin Manolache > Sent: Thursday, November 07, 2002 1:39 PM > To: [EMAIL PROTECTED] > Subject: Re: [VOTE] Proposed jspc refactoring > > > 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-> [EMAIL PROTECTED]> > For > additional commands, > e-mail: <mailto:tomcat-dev-help@;jakarta.apache.org> > -- To unsubscribe, e-mail: <mailto:tomcat-dev-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:tomcat-dev-help@;jakarta.apache.org>
