-----Original Message----- From: Christopher Schultz [mailto:ch...@christopherschultz.net] Sent: Monday, April 02, 2012 3:31 PM To: Tomcat Users List Subject: Re: Ant Tasks Question
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Nick, 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]Task.java. 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk96DJgACgkQ9CaO5/Lv0PCTwgCfc00h+M/g0IEK+7oaxQ8pq2yc /C8AoKC9kMhWLlsCt/rsJFXzmpmf8SrW =qK/l -----END PGP SIGNATURE----- --------------------------------------------------------------------- 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 ecosystem. 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. Thanks, Nick --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
