DevOps
From APIDesign
(→NetBeans and Command Line) |
(→NetBeans and Command Line) |
||
| Line 14: | Line 14: | ||
Isn't this a dream for a [[DevOps]] lover? | 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 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. | ||
| + | |||
| + | 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]] is 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. | ||
=== Two Way Editing === | === Two Way Editing === | ||
Revision as of 16:17, 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 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.
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 is 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.
Two Way Editing
Just Set the Classpath Up
TBD: Other IDEs and the old version.
Follow
