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.
"CLI" as in ...? Sorry, I'm not familar with this acronym.
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.
Right, I agree.
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.
Even though I see one advantage with including compilation to class files in JSPC (simlicity, no need to set up Ant, which is not always available in the web app developers environment), I wasn't aware of the -compile option until this week (since it's not documented). I'm okay with removing it and handle compilation in other ways.
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'.
Not sure I follow. If you mean to do this in addition to fixing JSPC (with the -webapp option), it's okay with me.
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.
See above. Hans -- Hans Bergsten [EMAIL PROTECTED] Gefion Software http://www.gefionsoftware.com JavaServer Pages http://TheJSPBook.com -- To unsubscribe, e-mail: <mailto:tomcat-dev-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:tomcat-dev-help@;jakarta.apache.org>
