Kyle Smith

If you find yourself working Eclipse and a file you’re working on gets deleted inadvertently there may be some hope of recovery.

Right-click on the project the file was in and select Restore from Local History.  You’ll be presented with a dialog that lists recent file revisions in the project and be given an option to restore them.

Thanks to Stephen for the tip.  And yes, I probably do owe him brownies by now.

Note: I scheduled this post on Feb 2 but apparently it never went live.  So Stephen did get brownies at one point.

Tags: eclipse

The other day I ordered an Arduino Duemilanove from Maker Shed and in anticipation of its arrival I went and downloaded the Arduino software to play around with.  I ran it and immediately got this error, which has been reported a number of times in the forums and mailing lists:

java.lang.UnsatisfiedLinkError: /Users/kylesm/Downloads/arduino-0012/Arduino 12.app/Contents/Resources/Java/librxtxSerial.jnilib:  thrown while loading gnu.io.RXTXCommDriver

I tried rebuilding rxtx with 64-bit support as documented here and here and then overwrote the copy that shipped with Arduino but continued to get the same error.  I then got the idea of copying the library and JAR from Processing (upon which it’s based) since that works just fine.  Same error.

The final trick was to edit the Info.plist for the app and change the value for the JVMVersion property to 1.5* (which is what Processing does) and it worked perfectly because the 32-bit version of the JDK 1.5 is my second choice in the Java Preferences app:

So in the end I couldn’t get it working with a 64-bit JVM and didn’t need to rebuild rxtx, but thankfully Apple includes just about every version it’s ever produced so it wasn’t a big deal.

The problem is primarily due to the fact that the Arduino IDE uses a native library that was built without 64-bit support and I’ve got Apple’s 64-bit JVM set as my default for work.

Tags: 64-bit, arduino, java6, macosx, rxtx

Last month while sitting at a Barnes & Noble I picked up and read a copy of Venkat Subramaniam and Andy Hunt’s book Practices of an Agile Developer: Working in the Real World.  The book is a collection of good tips for developers to follow.  One of them in particular, #33, struck a chord: Keep a Solutions Log.

What is a solutions log?

You’ve probably heard of the idea before or seen analogous practices only under a different name: Star Trek had ship’s or captain’s logs, IBMers have runlogs, other engineers have daylogs.  In this case, a solutions log is a personal record of the problems you’ve encountered and the answers you’ve found to them, with the intent of documenting the answer for all time so you’re not burned by the problem again.  If you’re kind enough to post it someplace Web accessible, others won’t get burned either!

I got accustomed to logging my activities (and by extension, the problems I encountered) while working at IBM but have been rather lax about doing the same while employed by VMware.  Periodically I’d scribble notes on a sheet of paper while working but they never quite got organized or put in an easily-searchable form.

Since reading PAD I’ve been maintaining a plain text file with my progress as well as any problems/solutions I encounter.  It’s already proved useful a number of times, especially when engaging in design decisions with colleagues and I know there is a particular reason to not do something.  If you decide to try it out, hopefully you find the practice just as useful.

If you don’t want to buy a copy of the book (or read it in a bookstore), you can download a PDF except of the book that includes this tip from the Pragmatic Programmer website: http://media.pragprog.com/titles/pad/CodeAndDebug.pdf.  You can also find additional information about the book on its official page.

One other tip in a similar vein: if you post a problem to a discussion forum or mailing list, please please please follow up with the solution once you find it.  There’s nothing so frustrating as identifying people that experienced the same problem as you but not knowing how they solved it!

Tags: agile, daylog, pad, solutionlog

Came across another small bug with m2eclipse yesterday when editing an XML schema in a project that used  the Maven plugin for JAXB (jaxb2-maven-plugin).  You may find Eclipse complaining that it cannot build your project because of this error:

An internal error occurred during: “Building workspace”.
Provider org.apache.xerces.jaxp.SAXParserFactoryImpl not found

The underlying problem may be due to classloader funkiness with the embedded version of Maven (since command-line Maven works fine) or some transitive dependency not being handled correctly.

Anyway, the workaround mentioned in this bug on the Codehaus JIRA solved the problem.  The solution is to explicitly add Xerces as a dependency to your POM:

<dependency>
    <groupId>xerces</groupId>
    <artifactId>xercesImpl</artifactId>
    <version>2.8.1</version>
</dependency>

Once you’ve done that, right-click on your project in the Package Explorer and select Maven > Update Dependencies. Eclipse should then be able to rebuild the project.

Tags: eclipse, jaxb, m2eclipse, maven

Here’s a tip for a very specific problem I recently encountered when using Maven and the Felix maven-bundle-plugin in Eclipse, and I’m sure it can happen with other plugins. There wasn’t an immediate answer to this problem when I used Google to search for it.

When Maven is running in offline mode (set in the Maven section of the Eclipse preferences), if you haven’t specified a version for certain plugins — like the maven-bundle-plugin — Eclipse will report an error like this:

Project build error:Cannot resolve pre-scanned plugin artifact (for use as an extension): org.apache.felix:maven-bundle-plugin: Failed to resolve extension plugin: org.apache.felix:maven-bundle-plugin:maven-plugin:RELEASE

Maven outside of Eclipse will most likely continue to work fine, but Eclipse will be one unhappy camper.  Your project may even lose its Java nature if m2eclipse is unable to resolve the dependencies.

The solution is to either allow Maven to run in online mode (Preferences > Maven) or add a <version> element to the plugin configuration (see example below). It seems that specifying the version in the pluginManagement section of the pom.xml may not even solve the problem.

<plugin>
	<groupId>org.apache.felix</groupId>
	<artifactId>maven-bundle-plugin</artifactId>
	<version>1.4.3</version>
	<extensions>true</extensions>
	<configuration>
		...
	</configuration>
</plugin>

Once you make one of these changes Eclipse/m2eclipse should rescan the project and fix it.  If it doesn’t get fixed immediately, right-click on your project in the Package Explorer and choose Maven > Update Dependencies and Maven > Update Project Configuration.

Note: I’m assuming you’re using a stable development build of m2eclipse. The non-dev version didn’t have these options when I last checked.

Tags: eclipse, felix, m2eclipse, maven