After figuring out how to use Maven to write SWT applications, I figured it was time to tackle JFace.
If you read through the JFace wiki page above, though, it says that to use JFace + SWT outside of Eclipse we basically have to locate several dependencies, namely:
All of these are available in the standard installation of Eclipse IDE in the
Now, it would be a 10 minute job to manually search for, copy and paste the actual JAR filenames and execute the Maven commands to install those into the local repository with proper group and artifact ids.
Since I’m ‘lazy’, though, instead of 10 minutes I decided to spend a couple of hours writing a Ruby script to do this all for me (I originally started to write it in bash but I realized it’d be a lot easier in Ruby).
Here it is. Continue reading
I’ve been trying to get my feet wet writing code for the Eclipse platform. I figured a good first step is to become familiar with Eclipse SWT—the Standard Widget Toolkit, and work my way up from there.
Since I use Maven, I had to struggle a bit finding out how to configure my Maven project properly so that it’ll build an SWT app that’ll run both under Eclipse and from the terminal.
A little Googling brought me to Brice Lambi’s post on Maven SWT builds, but that was a little outdated.
In particular (and only after careful reading), the guide to Deploying SWT apps on Mac OS X says that the
-Djava.library.path=.. option is needed for Eclipse 3.2.2 and earlier. Apparently, starting with 3.4 all you need is your OS-specific JAR (see here).
Anyway, after much fiddling about, I was able to get it all working like so: Continue reading
Here’s a quick post for those who a) use Maven 2 and b) need to use Quartz 1.6.0 in their projects.
See now Quartz 1.6.0 has (run-time) dependencies on JTA (if you’re using it stand-alone, outside of a J2EE container) and Commons Collections – unfortunately, the Quartz pom.xml doesn’t specify these as dependencies.
So here’s a pom.xml you can use to base your project’s POM off from.
If you use Maven 2, and have been trying to use the Maven 2 Ant plugin (“
mvn ant:ant“), you may have been getting the following error:
The plugin 'org.apache.maven.plugins:maven-ant-plugin' does not exist or no valid version could be found
A quick check, however, at the Maven 2 Plugin Repository shows that the
maven-ant-plugin is right there. However, the latest published version is version 2.0 and for some strange reason (at least on my end) Maven doesn’t pick it up.
There is a workaround. Apparently, you can specify the full plug-in groupId, artifactId and version as mentioned in here in the maven-users mailing list. So you could go:
Better yet, simply configure the plugin through in your project’s
(Note that the plugin groupId, when not specified, defaults to
org.apache.maven.plugins which is correct, in this case.)
That should let you do
mvn ant:ant again any time!
I use Maven to manage my Java build process. Maven, like Ant, uses XML to store information about your project and how to build it.
Yesterday, a thought occurred to me – What if I wanted to write a script that would do post-packaging of the Maven-built artifact(s)?
For example, what if I wanted to take the Maven-built artifact and distribute it via an OS X disk image? Or even something as simple as packaging the source into a
A simple shell script would be easy enough to cook up – but without repeating myself, how could I do it such that the subsequent packages are named according to the same version declared in the Maven
This got me to thinking about how to query XML, possibly using XPath from a shell script or the command line. I thought I might have to roll out my own XML-XPath command line processor, but fortunately somebody else beat me to it (thanks, God for all the wonderful people on teh internets) with XMLStarlet.