Saturday, July 24, 2010

Finding the right place to put static JavaScript files in GWT

I work on in the UI group for a software team building a large distributed system. We use Google Web Toolkt (GWT) and Sencha's Ext JS extensions for GWT (GXT). And we've been running into some warnings when building the applications that were quite annoying:

[INFO] using GWT jars from project dependencies : 2.0.3
[INFO] establishing classpath list (scope = test)
[INFO] using GWT jars for specified version 2.0.3
[INFO] using GWT jars for specified version 2.0.3
[INFO] ---------------------------------------------------
[INFO] ---------------------------------------------------
[INFO] Running
[INFO] The development shell servlet received a request for 'tizakie.js' in module ''
[INFO] [WARN] Resource not found: tizakie.js; (could a file be missing from the public path or a <servlet> tag misconfigured in module ?)
[INFO] Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 16.982 sec
[INFO] Results :
[INFO] Tests run: 2, Failures: 0, Errors: 0, Skipped: 0
We're working with GWT 2.0 and the inclusion of static JavaScript resources are changed. So the odd thing is that the functionality supported by ``tizakie.js`` works fine. So when deploying the application, or just running it in dev-mode via the Firefox plugin, everything works as you might expect. It seems the crux is that the test JUnit servlet is not finding it.

I took the hunch and starting searching for the info/warning messages on Google and ended up finding the private method that produces the message in the GWTShellServlet. The servlet is only used during development (which I believe since the package is The interesting part was the name of the method: doGetPublicFile()

(I should also mention that we use Maven 2 as build engine so I was looking for the best place to put this file in the Maven directory structure)

So I tried placing the static file in a number of different places to no avail. The info/warning messages were still happening. I thought that if I place the static JavaScript file under, like specific in a GwtTestCase, then the development shell might find the file. After all, you have state a package name as your module name for each test case.

With the project's gwt.xml file coming under org/iplantc/de, I figured that putting the file there might get it resolved:

|-- discoveryenvironment.gwt.xml
`-- ...

But still no luck. One of my co-works and colleagues, Evan, stopped by my desk and I mentioned my frustration. He suggested putting the file in a directory named ``public`` under the base directory structure where the *.gwt.xml file for the project was, like so:

`-- org
`-- iplantc
`-- de
|-- discoveryenvironment
`-- public
`-- tizakie.js

This finally resolved the info/warning messages. I had seen in GWT In Action that they had their static JavaScript files under public directories for then ScriptaculousDemo, and I had seen the private method that produces the message. But I never thought to try this.

I will admit I should have documented all the places that I tried putting the tizakie.js file so I could produce that now. I'm looking to see if I really have done this correct. Or, perhaps, this is a artifact of something related to Maven 2 or just GWT. But it sure is not the most obvious approach to resolving the info/warning messages.

If anyone has suggestions on the appropriate way to include static JavaScript files (in a Maven 2 directory structure), please post comments. I know Maven 2 is not used by GWT development team, but if I know where the static JavaScript file should be in the WAR directory structure - I can figure out in Maven 2 how to make that happen.

Monday, July 19, 2010

Recover lost commits from a Git repository

This morning I managed to blast away a colleagues local commits. We were running into ``non-fast-forward`` errors when pushing and somehow I lost one of the local commits (which I'm still curious how I screwed that up). Anyway, I use the technique I wrote about almost 3 months ago (to the day!): "Recover a deleted branch from a Git repository"

The main difference was I was not after the dangling commit, but the commit just before for it (which would show after the dangling commit in ``git-log``).

So I use that command I borrowed from StackOverflow:

$> git fsck --full --no-reflogs | grep commit

Then, use ``git log --stat <commit-hash>`` on the identified hashes and look for the following commit that you're after.

I will 100% admit that this is in the realm of MacGyver - but I didn't want to be responsible for blowing away any of my co-workers code.