GWT4NB compiling even when nothing changed
Sam Halliday
There is an issue that constantly nags me every time I write a GWT app
in Netbeans... and that's the needless compiling. My primary project
at the moment has a GWT piece, JSP pieces and a REST piece. i.e. it's
not *just* a GWT client-side app. The problem is that anytime I ever
want to build the project or run tests, GWT4NB insists on j2js
compiling all the GWT client code... even if I have not touched it
since the last compile!
The Hosted Mode takes away the pain when it comes to working with the
GWT client code, but this is most painful when running tests on the
non-GWT server-side code. It basically means that every time I make a
change to the server-side code and want to test it, there is a 60
second delay when I have to wait for the GWT client code to be
compiled, even though it'll never be called and hasn't changed since
the last compile.
Are there any workarounds for this?
Jon Brisbin
It basically means that every time I make a
change to the server-side code and want to test it, there is a 60
second delay when I have to wait for the GWT client code to be
compiled, even though it'll never be called and hasn't changed since
the last compile.
MN
http://www.javaworld.com/javaworld/jw-04-2007/jw-04-gwt.html?page=5
Some Recipes to Improve Your Google Web Toolkit Development
<quote>
An additional tip: When testing different server code behavior in
hosted and web mode, I found it saved time to skip the GWT compile
part in my Gant script and to copy the pre-compiled JavaScript code
from a "temp" location instead. This made sense with compile times of
up to 10 minutes when having more than trivial client-side code. With
Gant it is very easy to incorporate a switch in the script that
controls whether you are compiling or reusing older JavaScript files.
The parameter for this switch is provided on the command-line, e.g.,
as ">gant -D 'compileGWT=yes' deploy". For details on this Gant script
see tip 8.
[...]
ip 8: Deploy Your Application with a Groovy Gant Script
It's truly great, trying out your application in GWT hosted mode, but
the real power of GWT comes when deploying your application to an
application server or servlet container like Tomcat. In this step you
need to create a "war" file that should be copied automatically to
your Tomcat "webapps" destination. Of course, you can do all the
necessary preparation, compilation, copy and other tasks with Ant and
ant-contrib, and, indeed, that was how I started. But with my Ant
script getting more complicated, I found the ant-contrib control
structures and property regex processing a little bit cumbersome.
After reading "Groovy in Action" with a recommendation for "Gant", I
decided to have the best of both worlds: Groovy + Ant = Gant.
Installing Groovy and Gant is just an matter of less than 10 minutes.
Then you can customize the 'build.gant' script with ordinary
properties coming from a 'build.properties' file.
As I mentioned before, I started with a familiar Ant script. It was
based on the work of Gautam Shah (see Resources). If you prefer
ordinary Ant over Gant, I suggest starting with Gautams's Ant script.
If you want the power and flexibility of a scripting language plus the
capacity of Ant, then I propose you look at my Gant script, too.
[...]
Reference:
Groovy Gant http://gant.codehaus.org/
To get the Gant script and the corresponding build.properties file for
easy GWT deployment to Tomcat, download sample code.
http://www.javaworld.com/resources/jw-04-gwt.zip
</quote>
maybe there some changes possible in the ant scripts of GWT4NB to
avoid a recompile?
on the other hand: why is a full compile needed to start the debug
mode in GWTShell? i ask this because i can change the sourcecode of
the client side without the need to recompile it - i need only refresh
at the GWTShell and i see the changes.
walden
What version of IntelliJ do you have? I'm on version 6.0, which is
fairly old now. In the settings->Google Web Toolkit, there is a "Run
GWT Compiler for Java modules on make" checkbox. I leave it
unchecked.
Walden
Jon Brisbin
I like IntelliJ, for the most part. It's really got a lot of great
features, including the built-in GWT support. But it was just slower
to develop in than eclipse. Plus, I'm using Django on the server and
there is basically no Python support in IntelliJ (I know there is a
plugin, but it hasn't been touched in years and it doesn't provide
much more help than TextWrangler for editing Python files) when
compared to PyDev for eclipse.
Maybe when IntelliJ releases their new version of IDEA, which is
supposed to include lots of great features like what I already have in
eclipse, I might try it again.
Thanks!
Jon Brisibn
http://jbrisbin.com
Sam Halliday
your own Groovy build script is not exactly what I had in mind. I'd be
prepared to hack the Netbeans ant scripts a little (remove a line here
or there), but I don't want to change the whole build system!
Has anybody got any workarounds for the "compile everything even if it
hasn't changed" problem when running non-GWT tests in Netbeans?
> To get the Gant script and the corresponding build.properties file for
James D
What happened to the development on the GWT4NB is it simply going to die or is it going to be updated and improved?
Sam Halliday
e.g. the persistence unit, and of course the deployment settings.
I'd be happy if I could just turn off Java2Javascript compilation when
running the tests.
I'd be happier if there was a more generic solution that did not do
the Java2Javascript compilation unless files in the "client" package
had changed.
Sam Halliday
build-gwt.xml file, if it were possible to put something like the
following in the definition for -post-compile
if (currentlyRunningTask == compile-test
|| currentlyRunningTask == compile-test-single){
return;
}
but I don't know how to do this in ant-speak... anyone have any ideas?
Sam Halliday
In the build-impl.xml file, I removed the depends reference to "-post-
compile" from the "compile" target and only explicitly added it to the
targets "dist", "dist-ear" and "run-deploy".
This means that the Javascript is never compiled when I run the
tests... yay!
A more elegant solution would be not to touch the build-impl.xml at
all, and instead have something in the -post-compile in build-gwt.xml
that uses the logic
if (clientJavaFilesDoNotNeedToBeCompiled)
return;
which would avoid ever needlessly invoking the Javascript compiler!
Sam Halliday
lines to the build.xml should also do it
<!-- HACK to workaround GWT compiling everythnig during the tests -->
<target depends="init,deps-jar,-pre-pre-compile,-pre-compile,-do-
compile" description="Compile project." name="compile"/>
<target depends="init,compile,-post-compile,-pre-dist,do-dist,-
post-dist" description="Build distribution (WAR)." name="dist"/>
<target depends="init,compile,-post-compile,-pre-dist,do-ear-dist,-
post-dist" description="Build distribution (WAR) to be packaged into
an EAR." name="dist-ear"/>
<target depends="init,compile,-post-compile,compile-jsps,-do-
compile-single-jsp,-pre-dist,-do-tmp-dist-with-manifest,-do-tmp-dist-
without-manifest,-pre-run-deploy,-pre-nbmodule-run-deploy,-run-deploy-
nb,-init-deploy-ant,-deploy-ant,-run-deploy-am,-post-nbmodule-run-
deploy,-post-run-deploy" name="run-deploy">
<nbjpdaappreloaded/>
</target>
jobirn applicant
----- Receiving the following content -----From: waldenReceiver: Google Web ToolkitTime: 2008-07-24, 19:38:41
Subject: Re: GWT4NB compiling even when nothing changed
Jon,
What version of IntelliJ do you have? I'm on version 6.0, which is
fairly old now. In the settings->Google Web Toolkit, there is a "Run
GWT Compiler for Java modules on make" checkbox. I leave it
unchecked.
Walden
jobirn applicant
----- Receiving the following content -----
From: MNReceiver: Google Web ToolkitTime: 2008-07-24, 16:16:43
Subject: Re: GWT4NB compiling even when nothing changed
Groovy Gant http://gant.codehaus.org/
To get the Gant script and the corresponding build.properties file for
easy GWT deployment to Tomcat, download sample code.
http://www.javaworld.com/resources/jw-04-gwt.zip
</quote>
maybe there some changes possible in the ant scripts of GWT4NB to
avoid a recompile?
on the other hand: why is a full compile needed to start the debug
mode in GWTShell? i ask this because i can change the sourcecode of
the client side without the need to recompile it - i need only refresh
at the GWTShell and i see the changes.
Scooter
compiles or moves new files. The only thing that I notice is that
debug is really really slow compared to running in browser. This was
not always the case.
rusty
I enable it as a plugin, and set up my project. As soon as I'm done
setting up I disable the plugin. This is to stop it overwriting my war/
nbproject/build-gwt.xml file
I then go in and edit the build-gwt.xml to set a few things up, like
giving the compiler more memory, and using ant to see if things change
or not when doing a build.
I also generally add more GWT modules as I go, just by changing that
file. As long as you're comfortable with Ant I find that the best way
to go.
Sam Halliday
throws exceptions all the time and introduces all kinds of templates
that just clutter my templates folder (I end up not using any of the
features). So long as the Hosted Mode works (which is all in the ant
script), I am very happy to also disable the plugin! Speaks wonders
about the usefulness of the plugin...
I'd still be very interested in hearing if anybody has a way of doing
the "if folder contents not modified since last compile, then exit
this target" solution.
MN
> or not when doing a build.
with ants so all ant things are "magic" for me)
MN
my steps:
- (i do not change the build-impl.xml)
- i past the hack in to build.xml at the end before </project> (and
correct the newlines)
- i start debug mode with the debug button
- (no changes to source)
- stop debug and start again
always it calls the GWTCompiler
:-(
what do i wrong?
Sam Halliday
Tests... not running the debug mode. In my case, the Tests have
nothing to do with the GWT client code (it's all unit testing of
server side classes), so there is no need to run the tests.
MN
but is there a solution to avoid the gwt-compilation if i run the
debug mode?
Yegor
Please note that there is no dynamic linking in GWT (unlike with Java
JAR files, Linux shared libs and Windows DLLs). The whole project is
compiled into one big self-contained blob of JavaScript. Consequently,
a change in one class may decide how other class which depends on it
will be compiled. You cannot compile the class which changed without
recompiling the rest of the classes. The reason for all of this is
that GWT concentrates on the end-user experience and less on developer
convenience. To facilitate the development process the hosted browser
seems like your best option. You may also consider splitting the
project into two projects, {project.name}-server and {project.name}-
client and let the server project depend on the client. Then you can
deploy the JSP pieces independently from the GWT pieces.
Yegor
Jon Brisbin
On Jul 25, 2008, at 3:42 PM, Yegor wrote:
> Please note that there is no dynamic linking in GWT (unlike with Java
> JAR files, Linux shared libs and Windows DLLs). The whole project is
> compiled into one big self-contained blob of JavaScript. Consequently,
> a change in one class may decide how other class which depends on it
> will be compiled. You cannot compile the class which changed without
> recompiling the rest of the classes.
I understand the constraints of the way GWT goes about doing its
business. There are always trade-offs. But I haven't seen much in GWT
that couldn't be massaged into an incremental compile. It probably
*won't* go in that direction (path of least resistance and
all...Google has to balance developer time with net gains as well),
but it *could*. It's also not completely accurate to say that
everything needs to be recompiled for every change. Maybe it does at
the moment because all the results of all that work the compiler does
is just forgotten at the end of the compile run. But dependency maps
could be kept around ("pickled" if you will...I use Python too :) and
used in the compilation process if that was important to the compiler
writers. I'm not naive enough to think it would be easy. But it seems
strategically possible.
> The reason for all of this is
> that GWT concentrates on the end-user experience and less on developer
> convenience.
My comments weren't about my own convenience, they were a reflection
on what my superiors think about things that take me longer to do than
by getting the same results using another technology. Maybe with an
external audience of customers we are begging to drop coin for us
things might be different. But the "customers" of my apps are the
employees of our company. We have to balance how long things will take
to develop against user experience.
Our current portal is hundreds of units of business logic with dozens
upon dozens of very complicated UIs (a mix of plain forms and Ajax)
that are mission-critical. Judging from what I've seen so far with my
smaller projects, if I were to launch into writing one of our
important applications in GWT, the compile time alone would make it
extremely difficult to justify to my superiors that the benefits of
GWT outweigh the increased development time. We have to turn out new
applications all the time at a pretty quick rate. They're all non-
trivial as well. It's not about convenience, but about $$$ and time
(or the lack thereof). GWT cuts my overall forward productivity just
about in half. For a large project that, for example, impacts our SOX
compliance and reporting, I'm just not willing to stick my neck out
there yet. Sorry.
> To facilitate the development process the hosted browser
> seems like your best option.
Not in its current configuration. Out-of-process hosted mode would
integrate very well with our development process, but the current
hosted mode browser paradigm is too different and too difficult to
work with compared to our current workflows. Our developers are not
Web 2.0 gurus. They're doing good just to keep up with traditional
Ajax. If it's more complicated than "edit a file and hit Alt-R to see
changes" they're going to be resistant to it. In eclipse, more than a
minor change in the Java code (while debugging hosted mode) causes you
to have to exit the hosted mode browser (eclipse complains about out-
of-date class files). Every time I have to close the hosted mode
browser and re-start it, I have to go through the login process and
get back to where I was. Unlike Firefox, the hosted mode browser
doesn't save my login information. Besides being annoying, those
little time-consuming speed bumps just plain suck. I'm sure some
developers are masochists enough (there have to be plenty like that
out there...vi is still alive! ;) that they can keep plugging away
telling themselves they're getting a better experience for their end
users so it's okay that I'm beating my head against this wall.
> You may also consider splitting the
> project into two projects, {project.name}-server and {project.name}-
> client and let the server project depend on the client. Then you can
> deploy the JSP pieces independently from the GWT pieces.
I have enough pieces as it is. :) We use a custom MVC-style XML
portal, so we already have quite a few pieces to every application. I
can just imagine what the other developers would say if I showed them
the results of the compile for the small project I'm working on now.
Those compiled files also wreak utter havoc with my Subversion-
controlled stuff. Subversion keeps wanting to replace old copies of
things. I end up with a mess of cache.html files, half of which are
out-of-date. Our automated staging and deployment process is based on
Subversion. It updates things on all the application servers in the
farm automagically. I can't deploy things cleanly any other way.
While I don't like everything about how GWT works at the moment, I
really like the concept of using Java to write Ajax apps. The layout
stuff is great and very solid. But there's no way I can just plug GWT
into our enterprise. There are too many distractions and caveats. If
all you're doing is an app that can be contained in one module and
deploy those files through something like FTP, etc...then I can see
where these small problems can be overcome. But the problems with
hosted mode, the round trip of compilation, and the mess of module
inheritance/dependencies mean we won't be using GWT in any significant
way for a while.
I'll keep using it in my own, smaller projects, though, because I
don't have the same problems of the enterprise here at work.
Thanks!
Jon Brisbin
http://jbrisbin.com
Jason Morris
<target name="-post-compile">
<property name="output.js"
location="${build.web.dir}/${gwt.module}/${gwt.module}.nocache.js" />
</target>
<target name="-pre-dist">
<condition property="gwt.compile.needed">
<or>
<not><available file="${output.js}" /></not>
<not>
<uptodate>
<srcfiles dir="${src.dir}" includes="**/client/**/*.java" />
<mergemapper to="${output.js}" />
</uptodate>
</not>
</or>
</condition>
<antcall target="do-gwt-compile" />
</target>
<target name="do-gwt-compile" if="gwt.compile.needed">
<!-- You can override this property in the 'gwt.properties' file -->
<property name="gwt.compiler.output.style" value="OBFUSCATED"/>
<property name="gwt.compiler.logLevel" value="WARN"/>
<java classpath="${javac.classpath}:${src.dir}" failonerror="true"
classname="com.google.gwt.dev.GWTCompiler" fork="true" maxmemory="512m">
<arg value="-out"/>
<arg path="${build.web.dir}/"/>
<arg value="-style"/>
<arg value="${gwt.compiler.output.style}"/>
<arg value="-logLevel"/>
<arg value="${gwt.compiler.logLevel}"/>
<arg value="${gwt.module}"/>
</java>
<property name="gwt.output.dir" value="${gwt.module}"/>
<move todir="${build.web.dir}/${gwt.output.dir}">
<fileset dir="${build.web.dir}/${gwt.module}"/>
</move>
</target>
As you can see, we also move the GWT compilation to pre-dist instead of
post-compile. I've also got the maxmemory set for the compile.
Hope this helps!
Sam Halliday
file?
This really makes me think that the GWT4NB plugin is completely
broken, and in fact, its only usefulness is providing a few ant
targets that could quite easily just be manually included in the
build.xml file anyway. I think I might just uninstall it and move
these targets into build.xml.
Sam Halliday
"gwt.install.dir" to allow the scripts to define the "dev jar" (which
is named dependent on the platform) and add them to the classpath
automatically when debugging or compiling. This would mean that in
Netbeans it is only necessary to add the the "user jar" and therefore
increase portability across machines (to workaround the naming, we
have symlinks from a gwt-dev.jar to the relevant jar for that
machine).
rusty
> with ants so all ant things are "magic" for me)
small file that you update when you GWT compile:
So before you compile:
<target name="check-dashboard-update">
<echo>Checking ${gwt.module.dashboard}</echo>
<uptodate targetfile="${build.gwt.dir}/.flagfile-$
{gwt.module.dashboard}" property="dashboard.uptodate">
<srcfiles dir="${src.dir}" includes="**/gwt/**/*" />
</uptodate>
<echo message="dashboard.uptodate: $
{dashboard.uptodate}" />
</target>
And your compile task depends on this:
<target name="compile-dashboard" depends="check-dashboard-update"
unless="dashboard.uptodate">
and at the bottom of the file you would update this flag:
<touch file="${build.gwt.dir}/.flagfile-${gwt.module.dashboard}"
verbose="true"/>
Let me know if that's enough information. I can't really give you an
ant tutorial here, that would be too hard, but if you can learn a bit
about ANT or find someone who knows it, this should all make sense.
MN
copy and paste (or attach) your full build-gwt.xml/build.xml (without
your secret settings) so i need no guess where to place some code
(because im not so familar with ant i can not decode your basic
directions like "before you compile" & "your compile task depends on"
etc). i see it later better with diff tools what is changing.
thanks a lot for your help.
Jason Morris
<?xml version="1.0" encoding="UTF-8"?>
<project name="etude" default="default" basedir=".">
<description>Builds, tests, and runs the project etude.</description>
<import file="nbproject/build-gwt.xml"/>
<import file="nbproject/build-impl.xml"/>
<target name="-post-compile">
<property name="output.js"
location="${build.web.dir}/${gwt.module}/${gwt.module}.nocache.js" />
</target>
<target name="-pre-dist">
<condition property="gwt.compile.needed">
<or>
<not>
<available file="${output.js}" />
</not>
<not>
<uptodate>
<srcfiles dir="${src.dir}"
</project>
This target depends on the updating of the <module>.nocache.js file in your web
directory, so it'll be up-to-date until you change your client source code ;)
Have fun!
MN
MN
i have some questions:
whats the difference to rusty's solution?
- rusty work with a touched file
- your solution calculate this everytime
as mentioned sam:
there are some problems with my existing build? maybe i have to copy
somehting from the build-gwt.xml to the build.xml?
Scooter
6.1 and it works as expected. If I edit one file and do run or debug
and only one file gets compiled and moved. If I drop in a supporting
image or other resource it only copies that file.
My only GWT4NB complaints are the maxmemory setting that is required
to be manually set so that my project will build and for some reason
the debug performance is slow compared to runtime performance in
javascript which wasn't always the case.
Thanks
Scooter
Yegor
It sounds like GWT is not suitable for your project. GWT uses Java's
standard code/compile/debug cycle (when using hosted browser) with all
its limitations (e.g. not always can you hot-swap class files). If
your team cannot convert from code/Alt-R to code/compile/debug and if
hosted browser's performance (mostly start-up and page refresh) is an
issue (and it will always be slower because of Java's classloading,
etc) then you should not use GWT, but a JavaScript toolkit (like ext-
js). Using hosted browser is very important. It is the only way to
avoid the long compilation of Java to JavaScript.
There are two things that GWT has which makes it different from
JavaScript toolkits:
1. Java language, which allows you to use all the goodies of the major
IDEs (code analysis, refactoring, etc).
2. Static typing in Java also allows the compiler produce more
efficient JavaScript code than even optimized hand-written JavaScript
code.
If these two benefits do not outweigh the burdens GWT brings to your
team and development process, then you should stick with plain
JavaScript. For example, are you sure that Java and Java IDEs will
improve your development productivity if your team is so comfortable
coding JavaScript? How the performance gain from using GWT will impact
the performance of the overall application?
My recommendation, you should not use GWT without using the hosted
browser. You will feel the difference even more as the project's code
base grows. Learn and accept its limitations and annoyances, but use
it.
Yegor