DevOps

From APIDesign

Wikipedia defines DevOps as those people who unify software development and software operations and try to automate them as much as possible. This essay is a note that reflects the NetBeans history from the DevOps point of view and was inspired by a recent StackOverFlow developer survey.

NetBeans and Command Line

Since version 4.0 (released in 2005) the NetBeans IDE focused on support for external build tools. The first one was Apache Ant. You could create a project in the IDE and in addition to the configuration files, also a build.xml Ant script was created. The build script shared all the configuration with the IDE. As a result you could go to command line and type:

$ ant build

The external Ant did exactly the same thing that would happen in the IDE! In fact the (these days Apache) NetBeans was so tightly integrated with Apache Ant that it used the Ant internally as a library to perform the building as well.

I'd say that was a revolutionary step, but it appeared naturally. It grew from the deepest Jesse's experience - he knew how hard it was to configure Hudson, Cron or how the continuous build system of that time used to be called. With NetBeans the configuration was easy: Generate your project and your automatic build script is ready.

Isn't this a dream for a DevOps lover?

Maven and co.

Later NetBeans also started to support Maven. As the Maven is a way more declarative (compared to Ant), it was much easier for the IDE to understand the build scripts written by other people without using NetBeans. As a result following magic was possible: Check a project from a Git repository out and open (yes, open, not import!) the project in the IDE. The IDE reads pom.xml and figures out everything - classpath, source level, Javac options, Javadoc configuration and more. Just by having maven-exec-plugin definition section in the pom.xml the IDE immediately knows how to execute the project. And more. Again, as in the Ant case, the Maven is used internally and as such the products of command line vs. IDE builds are rarely different.

Btw. the whole project system is pluggable and extensible. As a result of that support for Gradle, JDeveloper, Eclipse project formats has been written as well and works the same: No import, real open! But from my perspective Maven support remains the best.

The whole cooperation with Maven is so smooth that I call NetBeans the GUI for Maven! This must be heaven for a DevOps guy, right? Just write your pom.xml and the IDE as well as your Jenkins will pick everything essential up automatically without additional effort.

Two Way Editing

The DevOps nirvana continues once you realize you don't need GUI to edit your project configuration. Everything, options, dependencies, plugins can be edited directly and once the pom.xml is saved, the NetBeans IDE picks the changes up and updates its internal state to them. The command line mvn install build always does the same thing as the IDE. The editors see the same classpath, the same sources. These days this is common in the Android+Gradle world, but when we started, this was unique.

Just Set the Classpath Up

On the other hand, there are problems of this approach. Configuring the classpath of your IDE is no longer just about adding path to a JAR file in a project configuration dialog (as usual in the other IDEs). If there is a problem, one has to dive into the pom.xml (or Ant's properties) and change that. The actual classpath and other project settings are influenced by various properties computed and derived from one another in relatively complex and tool (Ant or Maven) specific ways. Just by changing a seemingly unrelated property one can change the whole project classpath significantly. As soon as the IDE notices that, it may decide to reparse the whole sources. That may mean to throw away the caches to adjust to such change and burn a lot of CPU to generate new ones. Often resulting in the whole source tree turning red due to missing symbols.

This is not clueless - one needs to know what is happening and how to fix the problems. Recently we at least realized that in Maven case, if one JAR is missing from the classpath, then it doesn't make sense to reparse at all - and the IDE waits for the classpath to become 100% complete.

NetBeans: The IDE for Admins and DevOps!

Prior to version 4.0 the NetBeans IDE used the classical approach of fixed project classpath like other IDEs. While such approach is comfortable for Java developers (every one knows what a classpath is), it is very uncomfortable from the DevOps point of view: duplicating the IDE settings in a build script and continuous builder like Jenkins is just so much waste of time. The approach pioneered by NetBeans 4.0 where the IDE is just a GUI over project build script used by command line tool, is so much better when you care about your project from the code up to the final release bits.

The problem is that in common enterprises there is nobody who cares! There are various roles when a project is developed by a team. There are dedicated build and release engineers and those take care of the build scripts. On the other hand, there are developers, but they care only about the code.

The truth is that to find a good programmer is hard these days. Enterprises often hire people who can barely read Java (or other language they code in). To find a programmer who also understands some non-trivial algorithms without using StackOverFlow, is almost like a miracle. Refusing such candidates because they don't have good enough DevOps skills - e.g. they cannot read and debug Ant or Maven scripts - would be too luxurious. There are other guys in the team to handle that.

Enterprise developers thus just open the IDE and change the code. Edit, save (which should preferably recompile the needed pieces) and try the changes. Should they need to adjust libraries or change the build process they tell the build/release guys. That however means that the strongest feature that makes NetBeans IDE unique isn't useful for them at all!

NetBeans is the IDE for DevOps. With a sadness in my heart I use this to explain why NetBeans has always been popular among smaller teams and individuals, but never really started to fly among enterprises.