tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nick Williams <>
Subject RE: Ant Tasks Question
Date Mon, 02 Apr 2012 21:43:18 GMT
-----Original Message-----
From: Christopher Schultz []
Sent: Monday, April 02, 2012 3:31 PM
To: Tomcat Users List
Subject: Re: Ant Tasks Question

Hash: SHA1


On 3/29/12 10:07 PM, Nick Williams wrote:
> This works great for list, deploy, undeploy, stop, start, etc. All of
> those tasks work. But the jasper/jasper2 tasks are weird. They
> silently do nothing.

Hmm. I've been playing around with the JspC intermittently for about a year,
now, and I've noticed that the ant-i-fication of the JspC compiler seems to
be a bit of an afterthought. For instance, the class that implements it
isn't even called [something]

It's possible that this task in particular just doesn't work properly in a
namespaced context. Can any ant experts comment on that?

> Finally, there’s the matter of specifying a JVM. Other java/javac
> tasks allow you to specify an executable (javac)/jvm (java) to use
> when executing the task. I can’t find anything in the documentation
> that reveals a way to do this with the Jasper tasks. Can the Jasper
> tasks ONLY run in the same JVM as Ant?

Obviously, you can compile the .java files that the precompiler produces by
separating the translation (.jsp -> .java) and compilation (.java -> .class)
into two separate steps (where the latter is <javac>, which can be
customized in the way you describe). So, do you mean that you want to choose
the JVM that is used when actually performing the translation step?

It looks like JspC itself has a getFork() method that unconditionally
returns false. I'm not sure /why/, but this task wasn't expected to be able
to run in a forked context.

Without knowing the reasons for the above, I would say that in general
running in a forked context shouldn't be forbidden - rather it should be
expected of a nice player in the ant ecosystem. It seems like generating a
command-line from all the options taken from the ant attributes and stuff
shouldn't be in impossible feat.

Can you file an enhancement in bugzilla for both of these issues?

- -chris
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools -
Comment: Using GnuPG with Mozilla -



As for the ant-i-fication of the JspC compiler, I, too get the impression
that it was rather an afterthought. However, it is not necessary or even
that common for tasks to be called *Task, as Konstantin pointed out. Most of
them /aren't/ named *Task. However, if you are basing your comment on
Tomcat's naming standard for Ant tasks, then you do have a valid point. JspC
is the only Tomcat task that isn't named *Task. For that matter, it's the
only Tomcat task that isn't in o.a.catalina.ant.

I'm aware that I can translate and compile as separate tasks, but that's not
what I was looking for. I actually DO want to translate and compile with the
same task, because I want the Eclipse compiler shipped with Tomcat to be
used for compiling the JSPs. But your comment helps me out in expressing my
desire: I feel like it should be able to fork and use whatever JVM I specify
for executing the JspC task, whether I'm using JspC for translation and
compilation or just translation.

I agree that fork support should be expected of a nice player in the Ant

Maybe what we really need, instead of attempting to retrofit JspC to be more
Task-y, is add a new Task to o.a.catalina.ant (JasperTask? JspCompileTask?)
and trying to follow some better practices with the new practice. What are
the community thoughts on this? I can see both upsides and downsides to
doing this.

I'll file enhancement requests in Bugzilla later today or tomorrow for the
namespace and forking issues.



To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message