-----Original Message----- From: Konstantin Kolinko [mailto:knst.koli...@gmail.com] Sent: Monday, April 02, 2012 4:24 PM To: Tomcat Users List Subject: Re: Ant Tasks Question
2012/4/3 Christopher Schultz <ch...@christopherschultz.net>: > > 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? > Who cares how it is named? There are hardly any built-in Ant tasks that are named as *Task. See o.a.tools.ant.taskdefs package. I think you just cannot load both TC6 and TC7 implementations at the same time into the same classloader. Either one implementation or the other should win (or you would just get a mess). >> 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? Let's discuss first. Filing something is useless if it is loosely specified and if there is little community interest in it. Best regards, Konstantin Kolinko --------------------------------------------------------------------- The point of namespaces (in Ant specifically and XML in general) /is/ to avoid naming conflicts with like-named tasks. I successfully use namespaces for accessing all of the other tasks for Tomcat 6 and 7 without one or the other "winning"; there's no reason I shouldn't be able to do the same with the JspC task. For that matter, loading them both isn't even the issue, it appears. If I remove the "tomcat6" namespace from my Ant file and /only/ have the "tomcat7" namespace, "tomcat7:jasper" still doesn't work. Furthermore, if I declare explicit tomcat6-jsp-compile and tomcat7-jsp-compile tasks in the same Ant task, they /do/ both work perfectly and independently without either of them "winning". So loading them both in the same Ant task isn't the issue. Calling it from the namespace appears to be. Which is very odd. I see no issues with discussing it a little more before filing Bugzillas. However, I would point out that the Bugzilla enhancement request is /exactly/ where you want to work on the specifications for the enhancement, IMO. It provides a perfect repository for the discussion on the specification for a particular issue. Nick --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
