Sunday, July 23, 2006

Setting Up Apache Derby Plugins with Eclipse

I recently needed to do some development with Derby, the all-Java embeddable database that's now an Apache project. Since I use Eclipse for development, I noticed that there was a plugin available for development. Here's how to get the plugin setup up in eclipse. Note that I go the non-source route whenever possible. If you're looking to poke around in the source or make changes, you'll have to follow the instructions on the Derby website.
  1. If you haven't already, install Eclipse. I was working off of a new laptop, and grabbed v3.2.0. You'll need at least 3.1M6 to use the Derby plugin according to the docs. Download, unzip, start.
  2. Download the latest Derby release. I snagged 10.1.3.1. Unzip it to a folder
  3. Download the derby_core_plugin_10.1.1.zip file from the downloads page. Note that I couldn't find the exact copy, but rather a 10.1.2 version. All the better, right? It's located in a link labeld 'zip'.
  4. Here's where confusion sets in. The docs on the Derby site say to install the core, ui, and plugin.doc pluggins, but the referenced .zip only appears to contain the core. Where to get the UI plugin from? That's when I start actually reading the instructions carefully. To get any sort of UI functionality from Derby in eclipse, you must extract the UI and help source via svn and build it manually.
  5. At this point, you need a Subversion client to get the source. You can either a) Use SVN command line to checkout the source locally, or b) use the subclipse plugin to check it out from eclipse. 'A' is easier in this particular instance, but I normally use 'b', so I'll describe it here. 'A' users can safely checkout and skip forward to step 13.
  6. Since this is a fresh install of eclipse, I don't have the Subversion plugin installed. Thankfully, the Subversion guys do it right, and have a link for use with the eclipse update manager. A mere 15 clicks later (totally unworthy of writing about, see here for instructions), I'm ready to go with subversion.
  7. Now for the fun stuff. Open the subversion repository view by going to Window->Show View->Other and selecting it from the tree.
  8. Now add a new SVN repository by clicking on the toolbar icon shown:
  9. Enter the url given on this page. At the time of writing, it was
    https://svn.apache.org/repos/asf/db/derby/code/trunk/plugins
  10. Now in your SVN Repository view you should have an entry for the derby site. Right click on it and select 'Checkout...' from the menu. I chose 'Check out as a project in the workspace'.
  11. We actually don't want a direct project from the checkout, since we are checking out a tree with 2 projects in it. I named the project 'DerbyPlugins' and hit 'Finish'.
  12. Once you have your 'DerbyPlugins' project, this means you have the source tree and an eclipse project around it. We want to delete the latter, and only the latter, so right-click on it and choose 'Delete...'
    In the dialog, make sure to choose 'Do Not Delete the Contents' and hit 'Yes'
  13. Now you want to create the real projects. Choose File->Import...->Existing Projects into Workspace. For the root directory, navigate to your workspace and find the 'DerbyPlugins' folder. Now find the eclipse/org.apache.derby.ui folder and hit OK and Finish to close the dialog.
  14. At this point, you can skip to the next step, or test it out. To test, choose Window->Open Perspective->Other->Plug-in Development. Then right-click on your project and select Run As->Eclipse Application. This will launch a new eclipse runtime with the plugin active. You can create a new project in the new runtime, and you should have an Apache Derby option on it's right-click context menu:
  15. To create the deployable plugin, right-click the project (first close the 2nd eclipse window if you did step 14) and choose Export... In the resulting dialog, choose Deployable plug-ins and fragments and hit Next:
  16. In the next page, make sure that the org.apache.derby.ui checkbox is checked. Choose 'Directory' as the destination, and give it a folder to output to:
    Under the 'Options' tab, clear all checkboxes:
    Hit 'Finish'
  17. Now you have a deployable directory that just needs to be copied over to your eclipse install. Navigate to the folder you chose to output to in the previous step, and copy the org.apache.derby.ui_1.1.0 folder. Now go to your eclipse home directory, find the plugins folder, and paste it there.
  18. Restart eclipse (If you have a FAT32 filesystem, you will likely also have to follow the directions here to workaround an eclipse bug with this type of plug-in install). Now when you right-click on a Java project, you should have an Apache Derby menu item. Adding the Derby Nature to a project will add the necessary jar files to develop with, and also give you subsequent access to the Derby tools.
That's it for the install. Hopefully it was all worth it, but I'll find that out soon enough. If you want the docs installed also, go back to step 13 and do it for the org.apache.derby.plugin.doc directory as well.

Monday, July 17, 2006

Lego NXT Impressions



I should've got on this sooner. From reading online, I was one of the first recipients of a shipping Lego Mindstorms NXT system last month and I really could've had an early scoop, even before Gizmodo. I was on the waiting list all of one day before I got the shipment notification, and then was off for a 1 week vacation.

But that's not the real reason. I'm actually behind b/c I had a legitimate use for the NXT - it's part of my thesis project on controlling devices with dynamic bluetooth UI's. So for the first non-vacation weeks of my system, I spent it hacking, researching, and begging for early open-source info... especially on the byte codes to directly control the NXT over bluetooth, without any LabView programs.

I'm happy to say that it looks like that part of the project is going to be a success, although (for reasons I'll post later), I'm still very anxious to get ahold of Lego's upcoming developer toolkits. I had to do some serious online begging to get the byte-command information to drive the NXT outside of the LabView environment.



So, impressions from someone that had a real reason to use it (however convenient)?:
  1. It's very easy to get started. The kit has some worthwhile projects to build out of the box, although you'll need to follow instructions in the labview environment for some.
  2. LabView is really interesting. Somehow I've gotten an undergrad degree in computer engineering and 75% through a Master's in software engineering without ever using it. I know this is a simplified version, but thinking from a non-programmer's perspective, it could be highly functional and even intuitive. That said, from the programmer's perspective, it's limiting, and gets very cluttered very fast for relatively simple programs.
  3. Having bluetooth built in is a huge plus. No problems connecting to my PC and downloading programs. However, it appears to be a somewhat proprietary communications format on top of the serial port profile that adds mailboxes and severely limits message lengths. That was very bad news for my project. I'm sure this simplifies things greatly for the non-BT crowd though.
  4. Too little memory, as others have noted. The thing should really just have an SD slot
  5. I really wish there was 1 more motor and motor port. All of the ideas I had required 4 degrees of movement, which is not possible (although 3rd party vendors will likely have a solution for this soon).
  6. The support for the NXT by the newly released Microsoft Robotics Studio was a pleasant surprise. They require an intermediary PC to process and send commands to the NXT, and it ultimately inspired a partial workaround in Java to the BT message length limit problem.
  7. It's been about 20 years since I last used Legos, and sometime during that point I unknowingly lost my patience for hunting for the right tiny plastic pieces in a pile of other plastic pieces. I used to live for it as a kid, but now I kind of wished it shipped with one of the robots pre-assembled.

All in all it's a very promising kit. The fact that it will be open source will likely drive a wave of usefull API's and toolkits that will make the platform invaluable. I'm just glad, at 32, to have a valid reason to buy Legos again.