Was playing around with GWT and found it a little annoying using either shell scripts or cumbersome ant targets to compile the code, so I've written an Ant task extension, and made it available on my site http://www.nsshutdown.com/viewcvs/viewcvs.cgi/GWTAntTasks/
It essentially creates a new ant task gwtcompile, allowing you to simply have targets like:
I'll contribute it to the google repository, once I have time to deal with the paper work and of course if google will accept it. But please feel free to use it in the mean time.
Occam's razor. Why is this needed? Does it provide any features I can't use by calling the compiler with a <java> task element? I'm sure it was a useful exercise for you, but what does adding one more way to invoke the compiler from Ant get me? Note, it may seem less cumbersome, but to use a custom task requires a new configuration step in build scripts that isn't required otherwise.
> Was playing around with GWT and found it a little annoying using either > shell scripts or cumbersome ant targets to compile the code, so I've > written an Ant task extension, and made it available on my site > http://www.nsshutdown.com/viewcvs/viewcvs.cgi/GWTAntTasks/
> It essentially creates a new ant task gwtcompile, allowing you to > simply have targets like:
> I'll contribute it to the google repository, once I have time to deal > with the paper work and of course > if google will accept it. But please feel free to use it in the mean > time.
Most things in life are not needed, but desired Quote from the making it better page http://code.google.com/webtoolkit/makinggwtbetter.html **Cut So that's what GWT is all about. It's also useful to say what kinds of things GWT isn't about... Language wars Why does GWT support the Java programming language instead of language X? In a word, tools. There are lots of good Java tools. That's the entire explanation. It isn't that we don't like language X or that we think the Java programming language is somehow superior. We just like the tools. **Paste
Here is a step that simply makes it easier for developers, an addition to the tool that makes it simpler. Is that not the Zen of GWT?
A standard java task for compiling looks like: <java classpathref="gwt.path" fork="true" classname="com.google.gwt.dev.GWTCompiler"> <jvmarg line="-XstartOnFirstThread"/> <arg line="-out www/"/> <arg line="com.pjaol.test"/> </java>
This simply takes the hassle out of it, and reduces it down to <gwtcompile src="src" out="www" module="com.pjaol.test" >
We actually had a GWT compile Ant task internally, but then we discovered the new Ant 1.6 features like <macrodef> and <import>. I'm thinking at this point the thing that would require the least amount of configuration would be a really well-written macrodef. Something better than the "gwtc" task in here:
> Was playing around with GWT and found it a little annoying using either > shell scripts or cumbersome ant targets to compile the code, so I've > written an Ant task extension, and made it available on my site > http://www.nsshutdown.com/viewcvs/viewcvs.cgi/GWTAntTasks/
> It essentially creates a new ant task gwtcompile, allowing you to > simply have targets like:
> I'll contribute it to the google repository, once I have time to deal > with the paper work and of course > if google will accept it. But please feel free to use it in the mean > time.
I don't think that maxim is as useful in software dev as is Occam's Razor.
> A standard java task for compiling looks like: > <java classpathref="gwt.path" fork="true" > classname="com.google.gwt.dev.GWTCompiler"> > <jvmarg line="-XstartOnFirstThread"/> > <arg line="-out www/"/> > <arg line="com.pjaol.test"/> > </java>
> This simply takes the hassle out of it, and reduces it down to > <gwtcompile src="src" out="www" module="com.pjaol.test" >
I dislike it because it needlessly removes one's ability to inspect the command line parameters, such as the JVM -X option you passed.
Custom tasks in Ant were once very useful as the *only* way to seriously extend Ant. But then a canon of custom tasks emerged and tasks like <macrodef>, <script>, <java> and <exec> allow you to do most things in Ant without writing a task that needs to be compiled, deployed and configured.
On 1/8/07, Scott Stirling <scottstirl...@gmail.com> wrote:
> I dislike it because it needlessly removes one's ability to inspect > the command line parameters, such as the JVM -X option you passed.
The one nice thing a task/macrodef gets you is the ability to infer where GWT is installed (from a system property or environment variable) and the ability to set default values for certain things (like out="www", src="src"). In theory, you could have a gwt compile that looked like:
<gwtc module="com.pjaol.test"/>
The one nice thing this gives you is not typing the same values over and over. So if your convention changes, you just modify the task. Of course, this is a lot more useful in a large project than in a project where you're only using gwtc once.
> Custom tasks in Ant were once very useful as the *only* way to > seriously extend Ant. But then a canon of custom tasks emerged and > tasks like <macrodef>, <script>, <java> and <exec> allow you to do > most things in Ant without writing a task that needs to be compiled, > deployed and configured.
Yeah, Ant is much better now than it used to be as far as reuse goes. Back in the day, you had to copy-paste everywhere!
