Fork me on GitHub

n. Slang a rough lawless young Kuali developer.
[perhaps variant of Houlihan, Irish surname]
kualiganism n

Blog of an rSmart Java Developer. Full of code examples, solutions, best practices, et al.

Tuesday, August 14, 2012

KFS Archetype and kualigan-maven-plugins Restructuring Update

kualigan-maven-plugins-1.1.0 Released

You may remember kfs-archetype 1.0.5 and kfs-maven-plugin 1.0.8, but I have since merged these under the monicker kualigan-maven-plugins. This convention was originally established by ASF where plugins and plugin apis gather under a parent project. That is pretty much what I have done here at Github. The biggest reason I have done this is to pull in some other development and make it more accessible from a single place as well as create a structure for more plugins and archetypes (you didn't think I was going to stop with just kfs, did you?) For those looking for kfs-archetype and kfs-maven-plugin, they are still there. I have updated the documentation to clarify supported features and usages while also excluding features for future development.


One of the biggest features with this release is having JRebel support builtin. Previously, if you wanted hot-code replacement, you had to use the Hotspot approach or Jetty (pretty much the hotspot approach). If you wanted to use Tomcat, you definitely needed to use hotspot. Not only that, but hotspot requires you to start your JVM in jpda mode. For those unfamiliar, this is debug mode. With debug mode, you get some really great features.
  • It's slow
  • You can't change methods or classes.
  • It's slow.
JRebel is great. Here's a feature comparison with hotspot.

Setting up JRebel

I should really start with getting it. Once you've downloaded it, you need to setup your license. This is easy. Kuali Developers get a 1 year license (renewed annually) because Kuali is OSS. Simply apply for the license at

Setting up the license is easy. You can do this via your IDE. If you do not use a supported IDE (I use emacs), then you need to use an alternate approach. JRebel ships with a configuration wizard. You can run it like this:

Once you have you license setup, you need to configure your maven environment variables to use JRebel:

I put my JRebel in $HOME/jrebel

Once you have everything setup, you just execute the following from the maven overlay:

Until now, the recommended method was to use a run goal instead of run-war because running an unassembled war was the best way to track changes made to classes for hotspot modifications. Since we're not using hotspot modifications, we do not need to rely on the run goal. We can run a fully assembled war without having to shutdown the app server. Now, whenever a class is compiled, JRebel will pick up the change and make the necessary updates. No need to run jpda. Works with tomcat 7! That means, if you want to run tomcat like it were jetty, you now can.

Here's what it looks like:

What If I Already Have an Overlay?

With my overlays and those created from the kfs-archetype, I followed the convention set by the Rice project. That is, it is a multi-module maven webapp project. That implies there's a module where classes reside and there's a separate web module for constructing the war. I simply add the following to the war/pom.xml.

Notice that the jetty scanInterval is set to 0. This is setup this way so that jetty will not use the hotspot loading.

What's Next?

You probably already gathered this from looking at the github project, but here it is anyways:
  • kc-archetype for KC overlay projects
  • kc-maven-plugin to help run KC maven overlay projects
  • thinclient-archetype for making rice thin clients.
  • kuali-maven-plugin for generic kuali task project tools
  • Ruby on rails-ish database migrate functionality
  • Maven archetypes for liquibase custom refactorings.
  • Rice standalone overlay archetype


No comments:

Post a Comment