'. '

DevOps

From APIDesign

(Difference between revisions)
Jump to: navigation, search
(Maven and co.)
(Maven and co.)
Line 17: Line 17:
=== [[Maven]] and co. ===
=== [[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 buildscripts written by other people without using [[NetBeans]]. Just check a project from a [[Git]] repository and open (yes, open, not import!) the project in the IDE. The IDE reads '''pom.xml''' and figures out everything - classpath, [[Javac]] options, [[Javadoc]] configuration, 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.
+
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 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.
+
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 [[UI]] for [[Maven]]''! This must be heaven for a [[DevOps]] guy, right? Just write your '''pom.xml''' and the IDE as well as your [[Jenkins]] can consume them both with additional no effort.
+
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 ===
=== Two Way Editing ===

Revision as of 17:33, 14 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.

Contents

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

Just Set the Classpath Up

TBD: Other IDEs and the old version.

NetBeans the IDE for Admins and DevOps!

Personal tools
buy