My Experiences with Maven in IntelliJ IDEA and NetBeans IDE

DZone 's Guide to

My Experiences with Maven in IntelliJ IDEA and NetBeans IDE

· Java Zone ·
Free Resource

Thorsten Marx is a product manager and developer at e-Spirit AG in Germany. Read more about him here. 

Some weeks ago, I saw a colleague fighting IntelliJ's Maven support. A dependency was not detected by IntelliJ's Maven support and to fix it, he had to remove the dependency from the POM, save it, add it back to the POM and save it again. Hmmm... somehow not quite optimal.

This was the reason for me to take a look at IntelliJ's Maven support and compare some points with the support provided by NetBeans.

Handling Maven Projects

If you open a Maven project in IntelliJ, IntelliJ still generates a default project folder (".idea") and file (".iml").

This means IntelliJ must always ensure that data in the POM is kept in sync with its proprietary structures. However, IntelliJ only handles one direction. Changes in the POM are recognized and the project settings are in sync most times. But if you change something in the project settings, these changes are not reflected in the POM. So, as my colleague experienced, you have to do it twice.

Also, IntelliJ lists the "target" folder and ".idea" project settings folder in the logical project view, which is not useful most of the time.

In contrast, NetBeans uses the POM for pretty much everything. The Maven POM file defines the project, as shown below.

If you change something in the project settings, it is directly stored in the POM. Only in rare cases, e.g., if you redefine actions, does NetBeans need to create a specific file.

NetBeans only shows important information in the Projects window, as shown above. However, if you do want to see the Maven "target" folder, you can easily switch to the Files tab:

Building Maven Projects

When you build a Maven project in IntelliJ, with the default IDE commands, Maven is not used for the build process.

The same goes for tests. If you are using different profiles for local development and your continuous integration server, you have to use Intellij's Maven integration tab to build and test your project with Maven. This is really ugly because you cannot use all the shortcuts that make life easier.

NetBeans uses Maven for all that. You can simply press F11 or use the default toolbar button or menu item to build your applications with Maven.

This same action works whether you are using Maven, a plain NetBeans Ant build script, or Gradle. It’s always the same consistent procedure.

You can even change the Maven command that is used to build the project via F11. You are completely free to configure what you need:

Executing Maven Goals

Running Maven goals in IntelliJ displays a dialog with just two text fields and you have to type all the Maven parameters by hand.

Hey man, it could be so much easier.

Running a custom goal in NetBeans gives you a fantastic dialog with lots of possibilities. You can choose the profile, add properties, and even save everything to run it again later.

This saves a lot of work.


There are many more smaller issues that show that NetBeans has a smoother Maven integration than offered by IntelliJ. My impression is that  IntelliJ's Maven support is just an extension to its default project management system, since It still needs the default IntelliJ project folders and files. Meanwhile, NetBeans provides a much deeper and more complete integration.

One more thing. I’m not an IntelliJ user so please forgive me if there is a mistake in my observations.
I'm also not trying to start a new IDE war. What I want to do by means of this article is to get readers to think out of the box. If you are familiar with your IDE, that is great. If you are productive with your IDE, that is great. But if you think an IDE needs to be expensive in order to be a good product, you are totally wrong and should definitely give NetBeans a try.


Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}