DevOps

From APIDesign

Revision as of 09:53, 15 March 2018

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

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

at the command line and the external Ant did 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 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 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 the the pom.xml the IDE immediately knowns how to execute the project. And there is 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 such 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 isn't just about adding a JAR in a project configuration dialog.

TBD: Other IDEs and the old version.

NetBeans the IDE for Admins and DevOps!