Jibe - Introduction

What is Jibe 

Jibe is short for Java Integrated Build Environment. The Java Integrated Build Environment aims to provide middle-sized to large development teams, but also the open source community with a solution to build, test and release their software in a manageable way that increases both productivity, quality and ease of use.

Jibe is a combination of the following:

• Software Development concepts like Continuous Integration and CBD (Component Based Development).
• Tools like Ant, JUnit, CruiseControl and CVS
• A complete new way of integrating the building, testing and releasing of software

Targeted audience 

Jibe is targeted at middle-sized to larget development teams, as well as the open source community, working with layered software that needs a high degree of reusability. Jibe is especially suited for so-called software factories and component builders. Basically the following rule applies: if you have more than two modules in your CVS and at least one of those modules is used in more than one product, than you can benefit from Jibe. Standardizing your build, test and release process will give you major advantages.

A short-list of features 

Jibe has a lot of complicated features, more than we're able to list in 10 lines. Below you can find the most important ones, so you'll get a picture of what is possible when you're using Jibe.

• Layered building and testing (somewhat like the AFS model, which means application-functional-support), which makes it very easy to build a library of highly reusable software modules
• A continuously integrating build (iso a nightly build), meaning bugs will be found fast
• Testing of components (e.g. Enterprise JavaBeans) on multiple application servers (without having to modify either build scripts or code). For example, WebLogic, JBoss and WebSphere
• Automated build-label increments, including CVS-tagging and release generation
• Easy to use build scripts without too much control over the build process, so quality is maintained and all elements in the codebase are treated the same

How it started 

Jibe originated at SmartHaven, a company developing knowledge management solutions. The need for having a structured build environment that was capable of both building, testing and releasing software was big. During the development of our product at SmartHaven we encountered the problem that our build and release process was absolutely not manageable anymore. We were using Ant (see the resources section), but as might be clear if you know Ant, it absolutely doesn't guarantee your build process to be a success if you only use it without having thought about it. We're working with a team of about 15 to 20 developers and aren't all that organized. Everybody is working on multiple modules at a time, different products are maintained at the same time, bugs come in from the one side, feature and enhancement requests from the other. Then all of a sudden you go into the testing phase of your main product and you don't know where the hell you have to get your stable distribution from. These were the problems we were encountering. Everytime we had to release we were busy gathering documentation, binaries, scripts and configuration files. Nobody knew what version contained what and especially since we are having a lot of different functionalities and products in our codebase all reusing some modules, we had to find a solution for this. This was the beginning of Jibe.