I’ve had an opportunity recently to work on a product that needed an RIA web interface, and I chose my recent favorite tool for this, Vaadin. The services for this project needed to be highly scalable, and lent themselves well to functional techniques, so I selected Scala as my language of choice. I build my projects with Maven, for reasons I won’t go into right now, and I do much of my JVM-language work in Intellij’s excellent IDEA IDE.
Given these tools, I found a way to facilitate very rapid development of web UI’s, and I thought I’d pass it along.
Another technique I use, which I’ll expound on later, is creating “dummy” implementations of all of my backing services for my application. The “real” implementations are written as OSGi services, in separate modules from my UI. The UI is packaged as a war, but is also OSGi aware, with a bundle activator. This activator only gets called if the war is deployed into an OSGi container, and not otherwise. This allows the app to select which implementation of the services it uses – the “dummy” ones when it’s deployed outside of OSGi, and the “real” ones when they’re available.
This means I can use the handy Maven jetty plugin to quickly spin up my application and test it on my local workstation, without needing all of the dependencies (like a data store and such) of my real services. That’s good, in that I can get my “cycle time” down to a few seconds, where “cycle time” is the time between making a change and actually being able to test it in my browser.
We can do better, though.
I’m using Scala as my language of choice for building the UI as well, as it works just fine with Vaadin (and with everything else in the JVM ecosystem, for that matter, which is why I didn’t choose a non-JVM language – but that’s yet another rant).
I compile my Scala with the Maven scala plugin – here’s where the next handy bit comes into play. Turns out the Scala plugin has a goal called “cc”, for continuous compilation. Using this, I can fire up Maven with a “mvn scala:cc” command, and leave it running. Then I also use the “mvn jetty:run” command in another window to fire up the web application, and leave it running as well.
Here’s my configuration for the Scala plugin:
org.scala-tools maven-scala-plugin 2.9.1 compile testCompile ${scala.version} -target:jvm-1.5
And for Jetty:
org.mortbay.jetty maven-jetty-plugin 6.1.9 10 src/main/webapp jetty.xml file realm.properties stop 8889
Now I go back to my IntelliJ and start coding. Every time IntelliJ saves (which it does automatically unless you tell it not to), the Scala plugin compiles the files. This generates a new .class file, which the Jetty plugin (well, technically, Jetty itself) detects, and in response, reloads the running classes for the web application.
Net effect is that I can make my change and by the time I switch back to the browser, my new code is running. I test my change, emit the appropriate profanity, and go back to editing, all within a second or two.
This has profound effects on how you develop a UI, which every dynamic language aficionado knows (e.g. like Ruby/Rails or Python/Django). You don’t hesitate to experiment, and you get to see the visual effect of your changes right away. The good news is that I get to do this with my language of choice, and with all the power of the JVM ecosystem to support it.
The technique is not perfect – I’ve found that if you edit some resources or webapp files (images and such), it’s possible the Jetty plugin doesn’t “see” the change. Of course, two things help with that considerably: first, it’s lightning-fast to just Control-C the jetty plugin task and re-launch it, and second a Vaadin app generally doesn’t use many resources, unlike JSP or many other frameworks that make extensive use of templates.
Once in a while I’ve found the scala:cc task will report that it’s lost it’s connection to the “fsc” (fast scala compiler) background process – again, quickly control-c-ing the task and starting it again solves the problem every time.
Overall, I can crank UI out pretty darn quick with this method, and given that I can TDD even my UI code using Vaadin, I find the overall combination very effective and efficient.
I’ve blogged a few times about how Maven and it’s associated tools and plugins is much more than a build tool, it’s a project information and management framework, so it’s no secret that I’m a fan.
One of the lesser-known things about Maven’s project management abilities is in it’s release plugin – the ability for Maven to co-ordinate and manage your release process in a reliable, simple, and fully-automated way. That’s what I’d like to explore here.
If we’re developing in an environment that supports a fully deterministic build process, including dependencies (binary and source), then we need to be able to version all our build artifacts, whether they are jar files, war files, or any other kind of file. During the development process, we need to be able to assemble applications quickly without compiling any more than we need to, and without being forced to release modules that are still moving targets. This is accomplished in Maven by use of the “SNAPSHOT” versions of modules. A module, let’s say “app”, that produces a jar file, is at any point at some specific version, let’s say “1.1″. Once we create the artifact for 1.1, our next creation of that jar must not re-use 1.1, it must be something else, as changes are incorporated.
If we’re not ready to release 1.2 (and we probably aren’t if we just released 1.1, we need an “intermediary” between 1.1 and 1.2. This is 1.2-SNAPSHOT. By seeing the “SNAPSHOT” we know we’re dealing with a version that may and probably will change. Internally, Maven translates the “-SNAPSHOT” to a date/timestamp and serial-number combination that allows you to track quite precisely each SNAPSHOT version as it changes, if you want, but generally you just want “the latest” (like HEAD from Subversion), and this is just called “SNAPSHOT”.
When we want to release a new stable version, however, we want to reverse this process – we need to produce a new non-SNAPSHOT of our artifact, then immediately switch to the next SNAPSHOT version so that development can continue without interruption. In the case of our example, we’re going to produce app-1.2.jar, then immediately begin working on 1.3-SNAPSHOT.
During development, we may also want to specify our dependencies as SNAPSHOT versions as well, so if we have a dependency that is also in development, we can work on “the latest” version as well. Once we’re ready to release, though, this changes – we want only stable and reproducible code in our release, so we need to “resolve” all SNAPSHOT dependencies to a specific version, then we can switch our own module to a release version, probably tag the code at that point in SVN, and create the releaseable artifact. We probably also want to deploy that artifact to a staging area, ready to be deployed into our production environment.
Maven’s release plugin does all of this for us, and more, in a reliable and fail-safe way.
Run in two phases, the plugin’s goal “prepare” does all of the verification work for us. It:
The goal “perform” actually performs the release, doing all the steps required to produce and publish a versioned artifact to our staging area (often a system such as Nexus), where it can be accessed as required to deploy to other environments.
The perform process:
There are other goals for recovering a failed release, doing “dry runs” of a deploy without actually changing anything, and even moving the deployed artifact into the target environment.
So why might you choose Maven’s deployment process over a custom-built scripted process?
There’s a few things you might consider when making such a choice:
In short, rolling your own process for deployment is a much more expensive and risky proposition than using a reliable and well-established tool such as Maven to do it for you.
