At Hippo we use JRebel a lot during the development of our CMS product. JRebel is a great tool and allows us to do live reloading of source code and enables us to develop the CMS product in a lot less time. The main reason that we use JRebel is that the the CMS suite itself is build from several multi-module Maven projects. JRebel helps limiting the amount of build, aggregate, package and redeploy cycles needed to test the changes and new features which we add to the CMS. For this specific scenario JRebel is excellent and it works really well, but most of the developers I meet are spending time on developing websites with Hippo CMS, which are usually less complex projects. For developers on those kinds of projects getting a JRebel license is usually a thougher challange, but don’t worry there are alternatives besides using JRebel that can also help you speed up development.
While working on a new Hippo CMS add-on I chose not to take the usual route by putting all my stuff on the Hippo Forge. My personal opinion about the forge is that it feels outdated, hard to navigate and lacks features with regards to what modern-day software developers would want. Sure the Hippo Forge gives us one central place to go to, but that can be solved by other solutions as well. For this particular project I chose to see how far I would come by combining different free for open source SaaS products and see how much value they could give me.
Personally I always like to read how other companies do software development, but sharing our way is probably just as interesting to others. In this post I will describe what a typical Hippo CMS development cycle looks like, how the product is build and how we do continuous integration at Hippo.
This post has been in draft mode for a couple of months now. I don’t know why it actually took this long to publish. Last year was a great year and a lot of things happened, so here goes.
I find that generating Maven project documentation is always a bit cumbersome with the default XDOC or APT (“Almost Plain Text”) syntaxes. This probably has to do with getting accustomed to using Markdown while doing my thing on GitHub, which is sort of the de facto standard there.