I'm currently evaluating/trying out JRebel, and will use this page to take a few notes.

With IntelliJ

• 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:

With Maven

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-141 - Getting issue details... STATUS )

Status

The first issue detailed below is the most problematic, since 4.5. We ended up harcoding a workaround for it in info.magnolia.objectfactory.configuration.LegacyComponentsConfigurer (see MAGNOLIA-4455 - Getting issue details... STATUS )

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 freemarker.ext.beans.JavaRebelIntegration and freemarker.ext.beans.BeansWrapper#isJavaRebelAvailable.

Issues

System properties

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-4455 - Getting issue details... STATUS . Other workarounds could have been to patch info.magnolia.init.properties.SystemPropertySource or MagnoliaServletContextListener.

Node2Bean / Content2Bean

The type mapping cached by info.magnolia.jcr.node2bean.impl.TypeMappingImpl and 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.

Filesystem dependency

 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:

magnolia.repositories.config
magnolia.repositories.jackrabbit.config

Or add the overlay to the rebel.xml of your webapp which also seems to work:

  <web>
    <link target="/">
      <dir name="absolute path to your webapp project/overlays/info.magnolia.magnolia-empty-webapp-4.5.7">
      </dir>
    </link>
    <link target="/">
      <dir name="/absolute path to your webapp project/src/main/webapp">
      </dir>
    </link>
  </web>

But as a general solution, using the ServletContext methods instead of java.io.File would probably be a better idea in anyway.

// how "app root dir" is set:
context.getRealPath("") : [...]/src/main/webapp

// how config files are further loaded:
new File(context.getRealPath(""), "WEB-INF/config/default/repositories.xml").exists() --> false.

// how it could work
new File(context.getRealPath("WEB-INF/config/default/repositories.xml")).exists() --> true.

FreeMarker

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 FreeMarkerHelper

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.

More Resources

• Using JRebel with IntelliJ IDEA - Webinar Recording