I'm currently evaluating/trying out JRebel, and will use this page to take a few notes.
- Install the JRebel plugin
- Enable the JRebel "facet" on each module of your facet where you want JRebel to be used (use the jrebel tab and check the boxes)
- Optional: using nightly builds of jrebel:
- Download: JRebel Nightly
- Unzip and configure the plugin to use the jar from this download:
- If you have a licence token:
If you're using a Magnolia parent pom version 28+, you can enable the
jrebel profile. (either in your IDE if you have it configured to build your project with Maven, or on the command line with
mvn -P jrebel ...) (since
BUILD-141Getting issue details...
The first issue detailed below is the most problematic, since 4.5. We ended up harcoding a workaround for it in
MAGNOLIA-4455Getting issue details...
It'd really be nice to come up with either a Magnolia module that enables all sorts of JRebel-niceness for Magnolia, and/or a JRebel plugin. See http://zeroturnaround.com/jrebel/resources/jrebel-plugins/ for details; it doesn't seem all that hard to do
There is a (partially working) Magnolia plugin in the latest nightly builds of jrebel.
FreeMarker also does some funky things for integration, without really having a plugin, afaik. See
JRebel adds a couple of properties in
java.lang.System#properties. One of them is
com.zeroturnaround.bundled.org.apache.commons.logging.Log; unfortunately, it interferes with component configuration using properties. When you start up Magnolia with JRebel you could see Guice having problems stating that
com.zeroturnaround.bundled.org.apache.commons.logging.Log doesn't have a public empty constructor. This has been worked around in Magnolia 4.5.9 with
MAGNOLIA-4455Getting issue details...
. Other workarounds could have been to patch
Node2Bean / Content2Bean
The type mapping cached by
info.magnolia.content2bean.impl.TypeMappingImpl might need to be flushed for n2b/c2b to work properly after classes were modified.
Perhaps this is something that could be implemented in c2b itself, much like FreeMarker has some built-in support for JRebel (see
freemarker.ext.beans.JavaRebelIntegration and its usage in
freemarker.ext.beans.BeansWrapper#isJavaRebelAvailable()), or simply by not caching anything when in dev mode.
This might not be relevant if you don't enable jrebel for your webapp module in IntelliJ.
Despite the fact that the rebel.xml file now seems to detect the overlays well (contrary to these year old forum posts), some files can not be loaded, because
Path.getAppRootDir() points to
src/main/webapp when JRebel is enabled.
Overriding these two properties and setting them to absolute paths seems to solve the issue:
Or add the overlay to the rebel.xml of your webapp which also seems to work:
But as a general solution, using the ServletContext methods instead of java.io.File would probably be a better idea in anyway.
Not related to JRebel, but I thought JRebel would help. In Intellij, I "compile" a .ftl; intellij tells me "file packaged"... but the template in my
target directory hasn't changed, so FreeMarker still displays the old one, despite a
NullCacheStorage configured in
See http://devnet.jetbrains.net/message/5317525#5317525 for updates. Turns out we don't even need to do anything to FreeMarker caching nor template loaders, but as far as my experiments go, the only way to get the template to be refreshed is to "make module".
When developing a Magnolia project, put this configuration in the POM of your module(s) and also make sure to include it in the POM of your Magnolia webapp.
Vaadin client-side code
JRebel is not required to re-deploy Vaadin (GWT) client-side code, because those Java classes are not really deployed anywhere: GWT compiler operates over the source files.
SCSS files with Vaadin
In order to be able to redeploy the SASS stylesheets with Jrebel the following actions have to be taken:
- Pre-compilation at Maven process-resources phase has to be disabled (see groovy-maven-plugin configuration in magnolia-ui-admincentral and magnolia-ui-vaadin-theme pom files).
- Vaadin production mode has to be disabled in the empty-webapp web.xml file (productionMode param has to be set to false).
After that Vaadin will re-compile the SASS files every time the app is restarted (I'd recommend using ?restartApplication query parameter in app URL) and JRebel will re-deploy them just like it would do for the Java classes.