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

Antw: [VOTE] Proposed jspc refactoring

As a user, I agree with Hans Bergsten's comments on the bug database. Being able to deploy a single war file with all precompiled JSP's to the webapp directory is a very useful feature. It would be bad for us if we weren't able to do that any longer. (Only thing to remember is to use the correct

[VOTE] Proposed jspc refactoring

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 webapp mode (with its r