Re: [VOTE] Proposed jspc refactoring

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 c

Re: [VOTE] Proposed jspc refactoring

It's better to look at it as a compiler. It's output happens to be java, but it acts a whole lot more like a compiler than a precompiler. Precompilers are usually more like macro preprocessors. On Friday 08 November 2002 07:05 am, John Trollinger wrote: > I have to disagree with this, jspc is a

Re: [VOTE] Proposed jspc refactoring

I dislike this option immensely. It's entirely contrary to what JSPC is for. It's a tool for generating servlets from JSP that do not require the entire JSP machinery. It produces a web.xml file that maps each jsp page to the generated servlet. The generated servlets are portable between servlet

Re: [VOTE] Proposed jspc refactoring

Costin Manolache wrote: Hans Bergsten wrote: Removing the CLI and keeping the basic functionality seems like a good idea. "CLI" as in ...? Sorry, I'm not familar with this acronym. Command line interface. jspc.sh, main() and the argument processing. Ah, I should have known ;-) Just use

Re: [VOTE] Proposed jspc refactoring

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

RE: [VOTE] Proposed jspc refactoring

I have to disagree with this, jspc is a pre compiler, not a webapp packager. John > 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 JS

Re: [VOTE] Proposed jspc refactoring

I am +1 of refactoring the code and do something less "overly complex". I just have a look at the code and start speaking french. ;-) I can help if needed. -- Jeanfrancois Remy Maucherat wrote: Hi, jspc is IMO overly complex, with many features nobody knows how to use, and nobody cares t

Re: [VOTE] Proposed jspc refactoring

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

Re: [VOTE] Proposed jspc refactoring

Hans Bergsten wrote: >> Removing the CLI and keeping the basic functionality seems like >> a good idea. > > "CLI" as in ...? Sorry, I'm not familar with this acronym. Command line interface. jspc.sh, main() and the argument processing. Just use the jspc task in ant. My understanding is that ant

RE: [VOTE] Proposed jspc refactoring (how I use jspc)

rammer, Point2 Technologies, Inc. (306) 955-1855 [EMAIL PROTECTED] -Original Message- From: John Trollinger [mailto:jakarta@;trollingers.com] Sent: Thursday, November 07, 2002 1:24 PM To: 'Tomcat Developers List' Subject: RE: [VOTE] Proposed jspc refactoring I have to time to go through and f

RE: [VOTE] Proposed jspc refactoring

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 h

Re: [VOTE] Proposed jspc refactoring

Costin Manolache wrote: 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.

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 j

Re: [VOTE] Proposed jspc refactoring

On Thu, 7 Nov 2002, Henri Gomez wrote: > Date: Thu, 07 Nov 2002 12:43:45 +0100 > From: Henri Gomez <[EMAIL PROTECTED]> > Reply-To: Tomcat Developers List <[EMAIL PROTECTED]> > To: Tomcat Developers List <[EMAIL PROTECTED]> > Subject: Re: [VOTE] Proposed jspc ref

Re: [VOTE] Proposed jspc refactoring

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 f

Re: [VOTE] Proposed jspc refactoring

Remy Maucherat wrote: > Costin Manolache wrote: > >> To clarify - I agree jspc has a lot of broken options and >> features. My use case is: >> >> 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 gene

Re: [VOTE] Proposed jspc refactoring

Another big advantage of using JSP -> servlet is that you didn't have security problems of code exposure ;) Hey, stop making fun of me, and get back to work ;-) Oui patron ;) -- To unsubscribe, e-mail: For additional commands, e-mail:

Re: [VOTE] Proposed jspc refactoring

Henri Gomez wrote: > BTW, no matter how I look at it, the practice of generating servlets > seems really ugly to me (of course, there are so many ugly things > about JSPs, I guess it's only one of them). Another big advantage of using JSP -> servlet is that you didn't have security problems of

Re: [VOTE] Proposed jspc refactoring

BTW, no matter how I look at it, the practice of generating servlets seems really ugly to me (of course, there are so many ugly things about JSPs, I guess it's only one of them). Another big advantage of using JSP -> servlet is that you didn't have security problems of code exposure ;) -- T

RE: [VOTE] Proposed jspc refactoring

What about trying to argue for why an error page returns error code 200? Martin -Original Message- From: Remy Maucherat [mailto:remm@;apache.org] Sent: 07 November 2002 16:10 To: Tomcat Developers List Subject: Re: [VOTE] Proposed jspc refactoring Costin Manolache wrote: > To clar

Re: [VOTE] Proposed jspc refactoring

Costin Manolache wrote: To clarify - I agree jspc has a lot of broken options and features. My use case is: 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. Actually, I d

Re: [VOTE] Proposed jspc refactoring

Costin Manolache wrote: To clarify - I agree jspc has a lot of broken options and features. My use case is: I'm using a similar way with jspc fr

Re: [VOTE] Proposed jspc refactoring

To clarify - I agree jspc has a lot of broken options and features. My use case is: Removing the CLI or any other options is fine for me. I don't

Re: [VOTE] Proposed jspc refactoring

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 d

RE: [VOTE] Proposed jspc refactoring

> > > +1 [ ] Remove the options > -1 [X] Do not remove the options > I think some of the options are useless and should go away, but some of them are (or could be usefull if they worked). Right now I don't think jspc meets many peoples needs, maybe it is time to find out the needs of users fo

Re: [VOTE] Proposed jspc refactoring

Remy Maucherat wrote: jean-frederic clere wrote: The problem is that keeping the options is where the work has to be done... Removing cost (nearly) nothing but brinks nothing. Probably the vote could be: [ ] - Remove the options [ ] - Keep the options _and_ fix them. I don't really agree,

Re: [VOTE] Proposed jspc refactoring

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

Re: [VOTE] Proposed jspc refactoring

jean-frederic clere wrote: The problem is that keeping the options is where the work has to be done... Removing cost (nearly) nothing but brinks nothing. Probably the vote could be: [ ] - Remove the options [ ] - Keep the options _and_ fix them. I don't really agree, as I think it's just too

Re: [VOTE] Proposed jspc refactoring

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