Some time ago we ran a survey asking a few questions about the build process, specifically the tools that are used to do incremental builds and how much time those builds take. We had over 600 responses, so now it’s time to count the results.
This is the first time that we’ve published results on the incremental build process, so the information is more likely to serve as a guide than an authoritative information source. That being said, the information is still quite interesting, and if it serves to start a conversation that improves the process of even one team, then we’re proud to have helped out. If you haven’t answered the 3-question survey yet, take two minutes and go for it – and do let your community know about it – as more answers trickle in we’ll update this post with the new data. If you’d like to play with the results on your own we‘ve provided all the data and our calculations in a handy Excel sheet that you can download here.
How to install and use JRebel (formerly JavaRebel) in GlassFish with Eclipse IDE
In the recently published Java EE Container Restart & Redeploy Report, the GlassFish v2 application container was the best of the fully fledged Java EE containers in the terms of time spent redeploying. That’s the good news. The not so good news is that on average respondents report spending 14% of their coding time waiting for server redeploys/restarts. That’s just over 170 hours annually, per developer – approximately 4.3 full weeks of development time. JRebel eliminates the need to redeploy in about 80% of redeploy situations – and it’s easy to get started. This tutorial explains how to install and use it step-by-step.
Here we assume that you are using Eclipse 3.x with GlassFish v2. Most of the steps will be applicable to other versions as well, but it may look different from the screenshots included.
NOTE: Although GlassFish is tightly integrated with NetBeans, the JRebel support for that IDE is in Beta at the moment – for now, we recommend using Eclipse or IntelliJ IDEA instead. We’ll make sure to announce when better NetBeans support is available (it’s coming soon).
First, take a quick look at how coding looks when using JRebel (formerly JavaRebel).
The latest stable version of JRebel can be downloaded here. Unpack it to a directory of your choice.
STEP 2: Installing JRebel Eclipse IDE plugin
The JRebel Eclipse IDE plugin was introduced with JRebel 2.0 and makes configuring and using JRebel considerably easier. You can install the plugin by going to Help » Software updates » Available software » Add site and use the http://www.zeroturnaround.com/update-site/ URL as the update site.
STEP 3: Make a rebel.xml for your application
In order to do it’s magic, JRebel needs to know where your classes and resources are. We’ll use a rebel.xml configuration file to tell it. This is mandatory when you deploy your app as a WAR/EAR. You’ll need to have one rebel.xml file per module. This includes both web and EJB modules. The rebel.xml configuration file should be placed in your WEB-INF/classes directory in the case of a web module and in the jar root in the case of an ejb module. Put it in the root of a source or resource folder in your project (the same place where the .properties files are).
If you use Maven you can use the JRebel Maven plugin that will generate the rebel.xml in accordance with the module pom.xml as described in the Maven Plugin configuration manual.
In 99% of cases, people tend to use one module per project. In these cases, the JRebel Eclipse IDE plugin can generate the rebel.xml file for you, on a per project basis. If your project is one of the exceptions, edit the file manually as described in the Installation manual, otherwise generate the rebel.xml like this:
Click on your project and pick Generate rebel.xml
STEP 4: Configuring the Eclipse WTP IDE
You may skip this step if you run GlassFish outside of the Eclipse IDE.
Open the Servers View and double click the GlassFish v2 that your application is deployed to (if you don’t see the Servers View go to Window » Show View » Servers).
Open Publishing and choose Never publish automatically.
It may seem wrong to disable automatic publishing, but as JRebel will take care of updates from now on it will just slow you down.
STEP 5: Configuring Eclipse IDE
Go to Window » Preferences and from there to Java » Debug » Step Filtering. Check Use Step Filters and Filter synthetic methods and Step through filters. Now check all the default filters and use the Add Filter button to add com.zeroturnaround.* and org.zeroturnaround.*.
Now go to Project » Build automatically and make sure it is checked.
STEP 6: Success!
To check that the installation was successful access a page that uses a class, change that class in the IDE, press Save, access the page again and look for the following message in the console:
Now that you’re up and running, it’s time to enjoy coding without the need to redeploy. If you have any specific questions JRebel, the Forum is the best place to ask, so that other people get to hear the answer as well. Otherwise, you can contact us at support@zeroturnaround.com.
If you like what you see, please give us a quick mention on your blog or twitter (you can even follow us here).
For those of you who have been keeping up with recent ZeroTurnaround news, even though there are shows like Big Bang Theory to distract you, you’ll know that JavaRebel has been going through a renaming process. Instead of choosing the name ourselves, we opened up the process to anyone who wanted to contribute ideas.
One of our primary concerns in renaming JavaRebel was losing the growing audience of people who have heard about it in passing, and noted to themselves that this is a tool worth trying out. So it was interesting to note that when community-sourcing a new name, familiar naming conventions are the most popular.
Of the 90+ comments on the renaming blog, and 100+ suggestions on our suggestion page, the name most chosen was “JRebel” — so that’s what we’re going with.
Now, there were also some VERY creative names proposed, and we’d like to thank the folks who took the time to come up with them. Here were some of our favourites:
RebelDeployer – from “Andy” who noted that it sounds like a Sith space ship… I thought it more relevant for the Alliance, but whatever.
RebelRebel (full of Bowie connotation) – from “Peter” and “CPJ”
Continuity – from kodeninja
JivaRebel – according to Chaikhanna, “Jiva” is Sanskrit for the immortal essence of a living being, which survives physical death. Or, in this case, repeated reloads leading to some refinement of the original.
Diponegoro – according to Hannu, “Diponegoro” was a Javanese prince who was the leader of the rebels in the Java War 1825-1830. A perfect historical match for words Java and Rebel.
And a few more that made us laugh:
JFireStarPowerLavaInfernoRebel – by Felipe Soares
44 Magnum or just Magnum. Tark Sammons comment was: “Think “Dirty Harry”, especially the “do you feel lucky punk” speech. It says fun, playful, and serious all at the same time. It conjures up images of Dirty Harry pointing a 44 Magnum at Eclipse while it is “Building Workspace” and reloading the context and putting that whole process out of its misery.” — Note: of course, I’m pretty sure that 44 Magnum is copyrighted too ;-)
TheTotallyAwesomeAppFormerlyKnownAsJavaRebelWhichHadToBeRenamedDueToSome*$&#^$# Lawyers ;-) — Note: Come on guys, it’s not their fault, they’re just doing their best to protect their IP, which is something I think everyone understands. If anything, our growing success and public recognition brought this upon us, so we’re not too worried about it. The key thing to take away from this is: we’re growing fast, lots of new people are talking about JRebel (formerly JavaRebel ;-), and the value of the tool for users is more important than any name we could call it. “A rose by any other name would smell as sweet… “, know what I mean?
Moving forward, we’ve got a lot of things to change, not least of all the…
Core
Release archive
javarebel.jar and boot loading
SVN hosted dist/web docs (FAQ, Install etc)
License generator + internals
JR banners
Test server container startups
Hudson/Matrix integration
Email templates
Plugins
JavaRebelJSFPlugin
MavenJavaRebelPlugin
IntelliJ Plugin
NetbeansPlugin
Eclipse
aspectj-jr-plugin
guice-jr-plugin
jboss-jr-plugin
jr-integration
jr-sdk
jr-servlet-integration
jr-utils
spring-jr-plugin
spring-mvc-jr-plugin
struts2-jr-plugin
tapestry4-jr-plugin
velocity-jr-plugin
wicket-jr-plugin
jr-autotest
jr-servlettest
jr-autotest-hudsonplugin
jr-idea
jr-old-idea
Infrastructure
Current online public docs
Website logos
Static content
Blog
Smart URLs zt.com/jrebel vs zt.com/javarebel
… hmm… and the list goes on.
We’re going to update as many of these as possible, as fast as possible, but if we miss something, feel free to let us know (as long as you do this after Sept 16th – give us a week at least, k?). If you’ve ever posted anything about JavaRebel, and you’re the organized sort of person who likes to keep things in the right place, it would be cool if you could update that too. “JRebel (formerly JavaRebel)” would be most appropriate.
For everyone who participated in the renaming – we heartily thank you for your input, and look forward to hearing more from you! If you’re interested in letting us know what you think about JRebel (the tool, not the name), let us know here.
Although this tutorial concerns the Tomcat container, exactly the same instructions also can be used for JBoss and Jetty containers.
Compared to other containers out there, the Tomcat web container is one of the fastest when it comes to startup and redeploy times. Still, in a survey we conducted, developers estimate spending 18% of their coding time (about 145 hours annually, per developer – somewhere between 3-4, full, 40-hour workweeks) waiting for applications to redeploy. JRebel eliminates the need to redeploy in 80% of situations, and it’s easy to get started. In the embedded video you can take a quick look at how coding looks when using JRebel.
Tutorial
In this tutorial we explain how to install and use it step-by-step. We assume that you are using Eclipse 3.x with Tomcat 5.x or later. Most of the steps will be applicable to other versions as well, but it may look different from the screenshots included.
The latest stable version of JRebel can be downloaded here. Unpack it to a directory of your choice.
STEP 2: Installing JRebel Eclipse IDE plugin
The JRebel Eclipse IDE plugin was introduced with JRebel 2.0 and makes configuring and using JRebel considerably easier. You can install the plugin by going to Help » Software updates » Available software » Add site and use the http://www.zeroturnaround.com/update-site/ URL as the update site.
STEP 3: Make a rebel.xml for your application
In order to do it’s magic, JavaRebel needs to know where your classes and resources are. We’ll use a rebel.xml configuration file to tell it. This is mandatory when you deploy your app as a WAR/EAR. You’ll need to have one rebel.xml file per module. This includes both web and EJB modules. The rebel.xml configuration file should be placed in your WEB-INF/classes directory in the case of a web module and in the jar root in the case of an ejb module. Put it in the root of a source or resource folder in your project (the same place where the .properties files are).
If you use Maven you can use the JavaRebel Maven plugin that will generate the rebel.xml in accordance with the module pom.xml as described in the Maven Plugin configuration manual.
In 99% of cases, you probably use one module per project. In these cases, the JavaRebel Eclipse IDE plugin can generate the rebel.xml file for you, on a per project basis. If your project is one of the exceptions, edit the file manually as described in the Installation manual, otherwise generate the rebel.xml like this:
Click on your project and pick Generate rebel.xml.
Repeat this for all projects that you’d like to update with JRebel.
If you’d like to use one rebel.xml for your whole team, start with the generated rebel.xml, then replace the absolute paths to your workspace with a system property. JavaRebel will expand expressions like “${myProject.root}” in rebel.xml to a system property that you can pass to the application container as -DmyProject.root=c:/myWorkspace/myProject. This allows to you to use a single configuration for everyone and then customize it when starting the server.
STEP 4: Configuring the Eclipse WTP IDE
You may skip this step if you run Tomcat outside of the Eclipse IDE.
Open the Servers View and double click the Tomcat Server that your application is deployed to (if you don’t see the Servers View go to Window » Show View » Servers).
Open Publishing and choose Never publish automatically.
It may seem strange to disable automatic publishing, but as JRebel will take care of updates from now on it would just slow you down.
Open JavaRebel Integration and check Enable JavaRebel agent.
STEP 5: Configuring the Eclipse IDE
Go to Window » Preferences and from there to Java » Debug » Step Filtering.
Check Use Step Filters, Filter synthetic methods, and Step through filters. Now check all the default filters and use the Add Filter button to add com.zeroturnaround.* and org.zeroturnaround.*.
Now go to Project » Build automatically and make sure it is checked.
STEP 6: Success!
To check that the installation was successful, access a page that uses a class, change that class in the IDE, press Save, access the page again and look for the following message in the console:
Now that you’re up and running, it’s time to enjoy coding without the need to redeploy. If you have any specific questions JRebel, the Forum is the best place to ask, so that other people get to hear the answer as well. Otherwise, you can contact us at support@zeroturnaround.com.
If you like what you see, please give us a quick mention on your blog or twitter (you can even follow us here).
