Maven 3 Support in NetBeans IDE 7.0

the new beta build of netbeans ide 7.0 offers complete support for maven 3. (apache maven 3 release was announced in october, and focused on performance and usability improvements.) in this interview, netbeans engineer jesse glick speaks about what new and existing maven users should know about maven integration in the netbeans ide.

what types of maven projects can users work with in the netbeans ide?

any valid maven project can be at least opened in netbeans. java source roots can be opened with the usual code completion and similar features. general maven capabilities such as dependency management and starting builds can be done from the ide's ui (as well as directly in pom.xml, with various forms of code completion). the ide also provides special support for certain "packagings"--java ee applications, osgi bundles, and netbeans modules.

file > new project also offers a maven category so you can create new applications using maven. wizards are provided for some common project types such as java ee 6 wars. you can also pick from among the hundreds of "archetypes" (project templates) available to support popular technologies--everything from jira plugins to scala/lift apps to jini services. this is a great way to get your feet wet with a new framework.

with the release of maven 3, what has changed about maven integration in the netbeans ide?

opening projects should be somewhat faster. because the ide is using the official maven 3.0 code to parse your project, a lot of corner cases are now handled correctly that previously were not. and builds run from the ide by default use the bundled maven 3.0, which is generally faster than 2.x, and emits a number of warnings about configuration mistakes that ought to be fixed.

what other improvements in maven support are included in netbeans 7.0?

there have been numerous fixes and improvements to the maven support in 7.0 beyond what was needed to integrate maven 3.0. the netbeans 7.0 new & noteworthy page lists some of the more visible changes.

what is the level of compatibility for existing maven 2 projects and with new maven 3 projects?

actual builds use the regular apache-maven-3.0/bin/mvn executable, so they should behave exactly like builds not involving the ide. maven 3.0 is generally compatible with projects created for maven 2.x. there were a few listed incompatible changes which are typically easily fixed, and in many cases beneficial to fix even for 2.x users. from that list, the most common sources of problems i have encountered are:

1. projects which relied on profiles.xml now cannot move relevant profiles into pom.xml or settings.xml according to whether they are user-specific or sharable.
2. "legacy" repositories such as http://download.java.net/maven/1/ can no longer be used. fortunately, most content is already in proper repositories.
3. you need a new version of the site plugin to work under maven 3. the old version can still be used by maven 2 builds if you define a profile.
4. <parent> links need to use the actual version of the parent, and the actual <relativepath> if not ../pom.xml. maven 2.x failed to warn about this kind of mistake.

as far as the ide's parsing of maven projects and display of their metadata (such as dependencies), full compatibility with the 3.0 command line is intended. field testing should turn up any outstanding issues.

for those on the fence about maven, who have had challenges with it in the past, or who use other build tools, how will their experience in the netbeans ide be different?

first, maven differs from all other popular build tools in that the pom declares what the project contains and uses, rather than being a script in some sort of procedural language. (you can still insert bits of script using ant, groovy, etc. for unusual build tasks, but this is the exception rather than the rule.) this means that the ide can effectively read the pom and know what to present to the user: where source roots are, what the dependencies are, what build steps ("plugins") are in use, how plugins are configured. ide support for a build tool like ant is mostly limited to running the script and offering basic syntax completion when editing it, so netbeans defines proprietary metadata like the "nbproject" directory so it can open projects with some kind of structure. by contrast, netbeans can at least open any existing maven project, and important metadata is picked up directly from the pom. for example, the ide's java editor will automatically use the same classpath for showing live errors and hints as maven-compiler-plugin uses when actually building the project. ide features to manipulate the pom, like dependency conflict resolution, work directly with maven. there are plenty of littler features that make everyday development easier, too; for example, if your pom declares a popular license, file > new file will try to insert the appropriate copyright header.

furthermore, netbeans requires no "import" step to work with maven projects the way some ides do: if you have the project on disk, the project - or any file in it - can be opened right away, with no need for any ide-specific control files. you can also use team > create build job to ask the hudson continuous integration server to begin building and testing your project with no configuration up front.

second, maven's repository and dependency system is very powerful and helps you maintain comprehensible, properly layered software. libraries are cached in a repository, not checked in to source control. you can require that all components of your application depend on official releases of libraries declared in a single place - and this can even apply to libraries you wrote, so every component can be built in isolation. you do not need to check out a library project from version control just to get javadoc and sources for debugging - but you can check it out and start making changes with a single step from the ide. most popular free/open-source java libraries are already available in public maven repositories for immediate use. there is no need to manually download and manage jars and track down javadoc, and standard maven tools like maven-dependency-plugin can tell you if newer releases of any dependencies are available. maven-release-plugin provides a standard way to publish discrete releases of your own software, and repository managers like nexus can index everything and enforce consistency rules.

netbeans helps you work with repositories and dependencies with ease. perhaps you found a neat code snippet on a developers' site using some api you had never heard of before. paste it into the java editor, and a hint will appear suggesting you add that library as a dependency, based on the class name appearing in a public repository index.

browse the library under the dependencies node beneath the project and open javadoc, or pick a different version.

right-click the project and select show dependency graph to see if the library has any upstream dependencies you don't want, or which conflict with your preferred version.

open the maven repository browser window to see the universe of software in a searchable format (also integrated with the quick search toolbar); and open the metadata viewer for a library of interest so you can visit the project's bug tracker site, check out sources, or even find projects already using it.

comparing the performance of maven to other build tools may be missing the point, since the development models can be very different. compiling and packing classes into a jar runs the javac and jar commands regardless of the build tool, and the "compile on save" mode is available in netbeans for maven projects (including java ee) just as for any other. what is more interesting is that the ide's classpath scanning runs faster against a jar than a source tree, and the up-to-date check is far faster for a jar (i.e. a project-to-binary dependency rather than a project-to-project dependency). most dependencies in a maven project are against binary releases, so the ide's java editor does not need to constantly check for api changes in your classpath. this also works between projects you wrote, if you use "release" dependencies - making development of a very large java application potentially much more efficient than when using one big ant-based project or a tree of interdependent ant projects. "snapshot" dependencies can be used when you actually wish to work on parallel changes in two or more projects, in which case you pay the cost of the up-to-date checks just among those projects, and you can change your mind at any time just by switching dependency versions.

in parting, maven 3.0 is a long-awaited release and i am proud to work on one of the first ide integrations. i hope to see plenty of people trying it out in netbeans 7.0 beta and the nightly builds, and filing bugs early so the 7.0 release can be really polished in this area.