=== [[Maven]] and co. ===

=== [[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 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.

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.

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.

=== [[Maven]] and co. ===

=== [[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 the 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.

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 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.

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 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 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]] used in the enterprise). 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.

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!

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.

[[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.

=== Just Set the Classpath Up ===

=== 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 [[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.

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.

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.

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 the 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.

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 the 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 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 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.

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.

=== [[Maven]] and co. ===

=== [[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 the 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.

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 the 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 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.

=== [[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 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 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.

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 the 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 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.

</source>

</source>

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 to perform the building as well.

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.

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.

</source>

</source>

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 to perform the building as well.

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 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.

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.

Wikipedia defines [[wikipedia::DevOps|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.

Wikipedia defines [[wikipedia::DevOps|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 ===

=== [[NetBeans]] and Command Line ===