IDEs and Build Scripts

Interactive development environments (IDEs) are powerful productivity tools for software developers. While Java developers often work in Eclipse or IntelliJ IDEA (two popular IDEs), many projects also use automated integration build tools, such as Maven. The use of two different tools can cause inconsistencies if not well managed. This article discusses the risks that can occur when IDEs and build scripts diverge and provides guidelines for keeping the two views of the development project consistent while maintaining the relative benefits of each.

Let’s begin with an example scenario: Jim is very productive with Eclipse, his favorite IDE. To implement a new feature, he makes a change to a Java source file, runs the unit tests through the IDE, and sees a green bar indicating that all the tests passed. Since everything seems to have compiled and the tests ran, Jim uses the IDE to commit the changes to the source code repository and then takes a break for lunch.

When he returns from lunch, Jim notices an email from the integration build system saying that there was a compile error. Looking at the build log on the integration machine, Jim realizes that he forgot to update his IDE configuration to reflect the team’s decision to update a third-party library. The method calls in the code that he commited to the repository were deprecated (declared obsolete) in the prior version and are no longer valid in the current version. Simple enough to fix. Too bad that anyone who updated his workspace while Jim was at lunch had to debug a broken build.

Across the hall, Mary is engaged in a heated discussion with Phil, the release engineer. Phil wants to use Maven’s resource filtering to configure a properties file at build time. Mary is arguing that this is a bad idea, as the resource filtering puts a meaningless token in the source configuration file, which makes her IDE based debugging settings not work. In this scenario, there is a mismatch between the configuration of the developer’s IDE and the configuration of the integration build. In Jim’s case, the IDE settings were not updated to show the current state of dependencies as reflected in the Maven build scripts. In Mary and Phil’s case, an idiom (resource filtering) that works quite effectively in the integration build environment doesn’t match the way that a developer works within an IDE. These are two examples of how the differing ways that developers configure IDEs and configure build scripts can cause disfunction and conflict in the team. Fortunately, there are approaches to reconcile these differences.

The  IDE
IDEs can increase productivity for individual developers by enabling them to maintain flow, a hyper-productive mental state in which a person is fully immersed in what he is doing. Development practices support flow by working to focus the team on tasks that add value and to eliminate distractions, such as non-productive work.

IDEs help maintain flow by allowing developers to focus on the intent of their development tasks rather than the mechanics. This gives the developer more rapid feedback on the results of tasks such as refactoring, which enables him to perform refactoring tasks such as “move method” by indicating the code to be moved rather than having to perform the mechanical copy, paste, and search for compile errors elsewhere in a project. IDEs allow you to code without thinking too much about coding style conventions. A properly configured IDE can either format the code as you type or let you format it afterward. You need not worry about tabs, spaces, alignment, or other peripheral tasks, allowing you to