Blog

How to build Spring Integration (for Maven) locally... Posting this for my own reference as much as anyone else.

I was building a project I have that's using the Maven Andromda plugin to cross compile UML class diagrams into Java EJB3 entity classes. The plugin's worked flawlessly for a long time now, but this time it failed. It complained that it couldn't find the UML file that was referenced in the configuration file. It's no wonder: the file path it was looking for was doubled up, that is, it was equivalent to /myfolders/foo/uml.uml2/myfolders/foo/uml.uml2. I did some research and found this bug report. This proves that it wasn't my Andromda installation, but the Maven installation. This makes sense as I'd just recently upgraded from Ubuntu Hardy Heron (8.04) to Ubuntu Intrepid Ibex (what's an Ibex?; 8.10) and the package I was using (maven2) had been updated to 2.0.9. So, the moral of the story here is: make sure your Maven package didn't change under your nose.

Finally, JavaFX 1.0 – it's been 2 long years, but I'm glad to see this thing get going. Even if it shares the same fate as Silverlight and becomes a clumsier Flash, it's still a MUCH more agile Java. As the libraries enabled via JavaFX are all just Java code, you can still leverage them in standard Java. You needn't use JavaFX, for example. This means that the amazing integration with video and audio is yours for the taking.

Spring Integration is almost ready (website updates notwithstanding!)

IntelliJ 8.0's a large step forward (and none back!)

Matt Raible added Twitter updates to his blog. (Exhibit A). I decided to the do same. First, you'll need the twitter.js JavaScript. This can be found here. I would download this one. Install that script onto your site, ie:

I just visited the Phillipines. While there, my-brother-in-law gave me a hard disk with 60GBs of photographs. I wanted them on Flickr. Complicating matters further were the photos that my girl's photos. Her photos - every blessed one of them -- were perfect. Mine, on the other hand, were an affront to color, tone, lighting and God. Nothing short of a week in front of GIMP and Flickr could save them.

If you've ever used the testing support in prior versions of Spring you know that it was essentially JUnit 3.x, oriented. There were ways to make those scaffolding classes work for (my personal favorite) TestNG or even Junit 4, but they largely were engineering hacks, not real solutions. For example, with the TestNG case you could override the setUp method and annotate it such that TestNG would call that method for setup, while also complying with Junit's interface requirements. Now there's a better way. Here's how I got it workiung with Maven and Surefire and TestNG 5.7. First, I added support for TestNG 5.7 (which is current as of this writing.):

I stumbled upon the samples site from phpgwt.com – which features this application. The application seems to perform and work reasonably well in all browsers, although the transparent .pngs that are prevalent on the site don't seem to work well in Internet Explorer 6. Naturally, your mileage my vary, but I tested it against Firefox 3.0, Chrome, and Internet Explorer. Gorgeous. Similarly, look at the sample applications coming from ExtJS OR GWT-EXT. The first one's not quite as impressive as the second one, however, the second one may be at a dead end due to a licensing spat (as detailed here).

I've just open sourced and released on Google code an Open API for interacting with CDDA data from Java. Right now the API does basics, only:

Why is it that the basic 'optional' components on J2ME are pretty much the optional components on Android? What am I missing here? If you get a relatively new phone you're likely to get the same minimum requirements that you'll get from an Android phone – the things that are really interesting and attractive are optional, just as they're optional on J2ME. This applies, for example, to the GPS support, the ability to play MP3s, access the camera, etc. One thing I expect is that, because it's Google, that once you develop for Android and the phone "supports" the feature, then it won't be that hard to go from emulator to deployment on the handset with the same features. In the J2ME world, it's not easy to get an application that works identically once deployed without multi-hundred dollar certificates and so on. And of course, you still are better are programming to a common denominator if you want the application work across a lot of phones. Additionally, there are features that some phone supported that aren't supported in any one emulator, which means that testing j2ME is fine using the Wireless Toolkit but difficult if you're trying to access features from a Samsung A900 without then using Sprint's SDK. The Gphone is almost here, perhaps we'll start to get a feel for what that entails.

My first article for TheServerSide.com. I am very excited to have this finally happen, and am frankly really looking forward to doing some more. The article is a discussion on setting up an architecture using worklists that depends on jBPM and Spring.