Monday, 9 April 2012

GWT SDK Not Installed - Eclipse

From time to time, I have seen the simple but annoying message.
GWT SDK Not Installed
the error message is annoying because I "have" it installed, which means, not so much "not installed", but more "not detected" by the Google Eclipse Plugin.

As I am busy working on many things I forgot what the resolution was and again, spent 1/2 an hour resolving the issue.

You may find this error when using Maven and GWT. Essentially, the GWT SDK Library shows up as a Classpath Container. "GWT SDK [2.4.0]" or similar.

The cause is because Eclipse locates the "gwt-*" libraries in your "Referenced Libraries" set, before it sees the actual Eclipse "GWT SDK [...]" reference.

The error message occurs when theses other GWT libraries are in your classpath, in this case the "referenced" libraries section; especially before the GWT one.

There are two fixes for this

1. Move the GWT SDK to the top

Move the GWT SDK "Classpath" Entry Container above your "Libraries" where GWT is found. The Google Eclipse Plugin finds the SDK based GWT Library first and all is well. To move it, manually edit the .classpath file and move the classpathentry line to the top.

2. Exclude the other GWT Libraries from your classpath.

If you are using maven, you'll know that the Maven Eclipse Plugin can't specify the order of classpath references in the .classpath file.

The trick then is to "exclude" the gwt-dev, gwt-user jars from the generated .classpath file, which you can do in the pom.xml. This way, ONLY the GWT libaries in the Eclipse GWT Container are the ones seen by the Google Eclipse Plugin and it all works well. Note also I have the GWT ClasspathContainer for GWT in there, so when I DO regenerate the .classpath and .project files, I don't have to regenerate things.

The example pom.xml is as follows:

I hope that helps you.

Crashplan Active Bandwidth Control #2

In a previous post on crashplan - Crashplan Active Bandwidth Control - I setup a sophisticated "control" mechanism. I have now simplified my approach down to understanding my family patterns and I think it works as a guaranteed performance "setup".

Essentially, between the hours of 23:45 and 06:30, my backup is using ALL the available bandwidth. But I go a little more than that.

Crashplan only has an "on, off" approach regarding times. I wanted a "Fast", "Slow" approach around times. I am using UNIX cron and a script I wrote in the previous version which logs into Crashplan and adjusts the bandwidth.

My /etc/crontab looks like this .. finely tuned over the past 2 months.

So this seems to work real well, I have been able to increase my Backups to now pushing out 90G per week. Pretty good going.

Current 5 booksmarks @