Thursday, August 22, 2013

JRebel, Intellij, and maven placeholders - lessons learned

In my last post I have mentioned that there are some scenarios where using JRebel is not so straightforward. But it does not mean it's complicated. There are three steps needed: think, configure, and run. For those of you who need some sandbox for experimentation there is trivial project deployed to GitHub. There are several revisions that will illustrate the problems and solutions I am discussing.


The rule of thumb (in my opinion) is to work with the smallest deltas possible. Unfortunately, there are different conditions for capturing changes for different types of resources. Fortunately, we can handle most (if not all) of them.
The rebel configuration generated by the IDE plugin maps jar/war/ear config to default location. In case of jars, it is the build (target) folder. I am working with Intellij but my project's layout is defined by maven. Thus incremental changes to java classes are handled easily in the default configuration. Resource (like xml or property files) changes are captured by JRebel only if we update them in the build folder which (to my best knowledge) must be handled by maven. The situation of Eclipse users with m2e plugin on board is a way better as they can configure resource processing triggers.
Alternatively we can adjust rebel.xml configuration. In this way changes are captured as soon as files are saved. But ... This mode is not applicable when we have any preprocessing in resource files.
Finally, we can map several physical locations to a virtual one. There filtering mechanisms allow us to find the most optimal configuration for our needs.


JRebel can be configured in several different ways. First, the rebel.xml file might be generated by Eclipse/Intellij plugin (from what I've seen plugin for Eclipse is more powerful). Second you may configure maven plugin to generate rebel.xml file for you. Finally, you can just write it by yourself.
In the listing below a simple JRebel configuration for single module is provided: In this configuration the classpath of mod2.jar will be replaced with the content of build directory.
If we want to have to see immediate effect of the resource changes we can use the following configuration: In the above listening we combine the class path from two locations. The resources are monitored in source folder so every change triggers reconfiguration. Classes and other types of resources are collected from build directory. Thus, classes are updated on-the-fly after the recompilation.
Please note that in the previous scenario there will be an exception thrown in case there are maven placeholders in resource files. In this case we need to slightly modify our example. This way we capture instant changes to resource files, and changes to the property file triggered by maven resource processing.


This is it we have chosen and configured our application (maybe in a separate maven profile) to be run with JRebel. Run it from within your IDE, or as agent in standalone mode.
In my next post I will try to describe my observations on using JRebel for maven web modules.

1 comment:

Anton Arhipov said...

Nice post! Thank you for sharing!