Setting up a BD-J development environment sucks!

I’ve recently looked at how one can set up a Blu-ray development environment for developing Java apps on a PS3.
The HDCookBook project seems like a good starting place, since you need alot of files to surround your BD-J Java apps when on the disk. Fine enough, but expect some hassle of changing file names if you want to put them on a memorystick.
Next step, run ant for compiling the project… You need to download “BDJ.jar”. You can find it AFTER INSTALLING NERO ON WINDOWS. Aaargh. Three hours later, we’ve found our bdj.jar.
Java ME SDK? It requires you to register at Sun… Ok, done that. Next step, Install sun_java_me_sdk-3_0-ea-win.exe on Windows. I HAVE A MAC!!! AHRG! Who needs multi-platform portable javacode when you can distribute it as .exe files!?

Do they even want people to develop on their platform? This is not inviting! And stop the stupid Ant stuff. Maven is the only way of distributing sourcecode and knowledge that works.

Dissecting Grails for Maven building

Show me your war, and I will tell you how it does!

Upgrading a Java project from a legacy buildsystem to Maven involves lots of reverse engineering to understand how the application works. Starting to investigate a project by its deliverables is often the most easy, taking a working application and picking away piece by piece, like dissecting a frog, to see if it still works after some abuse and halfchanced guesswork.

I started by grails create-app‘ing a simple book tutorial grails app, and grails war‘ing it. The contents of the war were extracted into src/main/webapp of a maven demo project, supported by groovy-all, GMaven (Groovy Maven plugin) and Maven Jetty plugin.