https://issues.apache.org/bugzilla/show_bug.cgi?id=37515
--- Comment #11 from Mark Thomas <ma...@apache.org> 2009-01-04 16:45:42 PST ---
(In reply to comment #10)
> The issue with using compile="true" is that it does not give as much control
> over compilation. For starters we use a custom extension to the web app
> classloader to introduce another directory to the classpath *before*
> WEB-INF/classes.
That should be fine. If you set the classpath attribute of Jasper2
WEB-INF/classes and web-INF/lib get added to the end of whatever you set.
> We also
> use UTF-8 as the encoding for javac, but I believe jspc must do so internally
> as well -- as that's what it produces. [By the way, the documentation should
> really make the fact that jspc produces UTF-8 Java sources clear as this is
> not
> the normal default for Java sources or javac.]
I'll check what is going on and update the docs as required.
> I'm re-opening this since there is a use case for compile="false", but I'll
> understand if that use case is insufficiently interesting to everyone else (as
> we can work around this ourselves as well by not using pre-compiled JSPs when
> debugging).
I'm not clear what this use case is. What is it that you can't do with
compile="true" that you can do with compile="false"?
Note that I used the latest 5.5.x to test with the default build.xml for JspC
(from the docs) plus
classpath="${webapp.path}"
smapSuppressed="false"
compile="true"
and the Smap info was included in the class files.
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
