You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Christopher Schultz <ch...@christopherschultz.net> on 2012/04/02 22:31:20 UTC
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-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Ant Tasks Question
Posted by "Williams, Nick" <ni...@ul.com>.
FYI, effective immediately this (nicholas.williams@ul.com) is my new email address. I can no longer be reached at nicholas.williams@puresafety.com.
Nick
-----Original Message-----
From: Nick Williams [mailto:nicholas.williams@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:chris@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Ant Tasks Question
Posted by Nick Williams <ni...@puresafety.com>.
-----Original Message-----
From: Christopher Schultz [mailto:chris@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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Ant Tasks Question
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----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-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Ant Tasks Question
Posted by Nick Williams <ni...@puresafety.com>.
-----Original Message-----
From: Christopher Schultz [mailto:chris@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Ant Tasks Question
Posted by Konstantin Kolinko <kn...@gmail.com>.
2012/4/3 Nick Williams <ni...@puresafety.com>:
>
> The point of namespaces (in Ant specifically and XML in general) /is/ to
> avoid naming conflicts with like-named tasks.
Conflicts in XML file syntax. Is it more than that? Does Ant use
different class loader instances for each of namespaces? (Can you
confirm?)
With JspC the issue is not the tasks having the same name, but the
classes implementing those tasks having the same name.
> 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.
Other tasks besides JspC are just HTTP clients to the Manager web
application, that send GET or PUT request to it.
I would say that it does not matter much whether you use Tomcat 6 or
Tomcat 7 implementation of those tasks.
For JspC task it is essential to use specific version of Tomcat,
Moreover, it is essential to use specific minor version x.y.z as you
have on your server, because there is no guaranteed compatibility with
version x.y.w.
>
> 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.
Bugizilla e-mails go to dev@ list.
1. There are more people on users@ than on dev@,
2. It is easier to discuss on a mailing list, IMHO.
3. You can always add a link to the mailing list thread archive in
your Bugzilla issue.
Just my opinion. Do as you wish.
Best regards,
Konstantin Kolinko
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Ant Tasks Question
Posted by Nick Williams <ni...@puresafety.com>.
-----Original Message-----
From: Konstantin Kolinko [mailto:knst.kolinko@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Ant Tasks Question
Posted by Konstantin Kolinko <kn...@gmail.com>.
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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org