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
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
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
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 JSP
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
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
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
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
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
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,
ballot
+1 [ ] Remove the options
-1 [X] Do not remove the options
/ballot
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
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
To clarify - I agree jspc has a lot of broken options and
features. My use case is:
taskdef classname=org.apache.jasper.JspC name=jasper2
classpath
pathelement location=${java.home}/../lib/tools.jar/
fileset dir=${tomcat.home}/server/lib
include name=*.jar/
Costin Manolache wrote:
To clarify - I agree jspc has a lot of broken options and
features. My use case is:
taskdef classname=org.apache.jasper.JspC name=jasper2
classpath
pathelement location=${java.home}/../lib/tools.jar/
fileset dir=${tomcat.home}/server/lib
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
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 clarify
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 ;)
--
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
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: mailto:tomcat-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail:
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 generate the
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
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 refactoring
Remy Maucherat wrote:
Hi
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
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.
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
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 fix all the options (including cleaning
up the code) but I would like to see what
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's
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
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 to
29 matches
Mail list logo
