FYI, effective immediately this (nicholas.willi...@ul.com) is my new email address. I can no longer be reached at nicholas.willi...@puresafety.com.
Nick -----Original Message----- From: Nick Williams [mailto:nicholas.willi...@puresafety.com] Sent: Tuesday, April 03, 2012 4:57 PM To: Tomcat Users List Subject: RE: Ant Tasks Question -----Original Message----- From: Christopher Schultz [mailto:ch...@christopherschultz.net] Sent: Tuesday, April 03, 2012 9:03 AM To: Tomcat Users List Subject: Re: Ant Tasks Question -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Nick, On 4/2/12 5:43 PM, Nick Williams wrote: > 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. I was mostly gathering corroborating evidence to suggest that JspC being an Ant task was not its original intent: it's mostly geared towards being a CLI tool and has some support for Ant slapped-onto it. I'm not sure why Konstantin got so agitated about my comments about the class name: it's obviously the least significant part of my argument. > 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. Well, you can already do that from within JspC (though the CLI doesn't actually use it) by setting "compiler" to either "org.apache.jasper.compiler.JDTCompiler" or "org.apache.jasper.compiler.AntCompiler" (or really anything that implements org.apache.jasper.compiler.Compiler). The default is to use the JDTCompiler when the translate and compile steps are performed together. I have no idea how to invoke the JDT compiler from the command-line given just the .jar file that contains it: I suspect you'd be able to poke-around and figure out how to do that as a separate Ant task, which might give you more flexibility. > 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. Fair enough. Just because I'm curious: why do you care which JVM is being used for the translation step? > I agree that fork support should be expected of a nice player in the > Ant ecosystem. I'll have to read the code for some of the built-in Ant tasks to see how that's traditionally done. It might make sense for the Jasper and task to become a separate class from JspC, even if it heavily utilizes JspC itself. Ideally, JspC would be "merely" the CLI wrapper around a Compiler and a separate class would handle the Ant-related stuff. I would even buy a common superclass for the two, but it's often tough to tell what is there to support Ant and what isn't. > 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. Heh. I should have read this first. I obviously agree. > I'll file enhancement requests in Bugzilla later today or tomorrow for > the namespace and forking issues. I'll look for those. - -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/ iEYEARECAAYFAk97AyIACgkQ9CaO5/Lv0PCWjwCeIIJh0Qp9iooqN0ZRa23YOI55 GUwAoJGNiPlt/IO7r2PffDcEKKtDgdTu =qORp -----END PGP SIGNATURE----- --------------------------------------------------------------------- I have filed issues 53031 and 53032 to go along with 53011 and 53012 that I filed earlier. I look forward to working on them. I don't really care what JVM is being used for the translation phase. The reason I care what JVM is being used for the /compilation/ phase is that our build machine has multiple JVMs (Java 6 32-bit, Java 7 32-bit, Java 6 64-bit, Java 7 64-bit). Our Ant script should be run only using the Java 7 64-bit JVM. However, everything else in the build script (java, javac, junit, etc.) is configured to explicitly use the Java 7 JVM, so that if anyone ever messed up the build agent and switched it to using Java 6 to run Ant, everything would still compile under Java 7. Except that, in this case, the Jasper task would suddenly be running under Java 6. This isn't even a big issue for us, because if somebody messes up the build configuration, that just needs to be fixed. I understand that I can separate the translation phase from the compilation phase. But I want the compilation phase to use the Eclipse compiler, just like if it was running under Tomcat, and javac can't be configured to use the Eclipse compiler (that I know of). Like I said, it's not even a big deal for us, but it seems like, in the spirit of being like java and javac and junit and other language-dependent tasks, it should support providing and alternative JVM (and thus forking). This will likely be encompassed by the changes necessary for issue 53031 (the forking issue). Unless you have any objections, I'm going to move further discussions about 53011, 53012, 53031 and 53032 to the developer's list ("Improving Ant Task for JSP Compilation"), to keep from polluting the users list with too much specification information. Nick This e-mail may contain privileged or confidential information. If you are not the intended recipient: (1) you may not disclose, use, distribute, copy or rely upon this message or attachment(s); and (2) please notify the sender by reply e-mail, and then delete this message and its attachment(s). Underwriters Laboratories Inc. and its affiliates disclaim all liability for any errors, omissions, corruption or virus in this message or any attachments. --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
