Resources Blog Inserting artifacts in the m2eclipse POM editor

Inserting artifacts in the m2eclipse POM editor

In the upcoming m2eclipse release, we've reworked how inserting artifacts (dependencies, plugins, parents) works in the XML editor. Instead of generating a skeleton template snippet for you to populate with maven coordinates (groupId/artifactId/version) we reuse the Artifact Search dialog. This post is a glimpse into some of the functionality that will be available in the coming weeks.

Instead of expecting a user to supply these artifacts directly in the XML editor, you now have the option to search for an artifact and let m2eclipse take care of the details. We've also made some improvements to the Artifact Search dialog. Screenshots speak as thousands of words though so let's take a look.

Read the rest of this post to learn more about this new way to insert artifact coordinates in a Maven POM using m2eclipse.

Inserting a dependency using auto-complete

In the POM shown in the previous figure, I have invoked completion within the <project> element. I haven't started typing anything prior to invoking auto-complete and, as a result, m2eclipse shows me some extra insertion options: "Insert dependency", "Insert plugin", and "Insert reference to parent POM". In this particular example, I'm inserting a parent element. Since I have no parent defined in this project, m2eclipse gives me the option to "Insert reference to parent POM" in this auto-complete menu. As a courtesy we will use the current groupId as the initial search term as it is likely that your parent shares the same groupId and we want save you some typing.

The dependency and plugin insertion proposals appear in multiple contexts. Here it's <project>, but you will encounter them in <depedencyManagement>, <pluginManagement>, <build>, <dependencies>, and so on. If we are in <project> xml element, we will either generate the <build>/<plugins> elements as well (at the chosen location), or if you already have your <build>/<plugins> subelements defined, we will append the plugin definition there.

Support for managed versions

Child projects can inherit a set of default versions for both plugins and dependencies from parent projects that make use of dependencyManagement and pluginManagement elements. We call the versions defined in these elements "managed versions" - they allow you to specify a global version for any dependency or plugin at the top-level of a large multi-module project. If your dependency/plugin inherits managed versions (in parent POM for example) and you pick the managed version in the selection, we will omit the version element in the child POM.

Let's take a look at the Selection dialog now, because we made it easier for you to spot and pick the managed versions of your artifacts as well.

We've reduced the amount of information shown, so for each dependency/plugin you only get to see the version, type and classifier If you want to see more details, like size or date of creation, just select the appropriate tree in the node.

As you can see the ant-antlr artifacts appear with the lock icon overlay and a decorator text. Both of these attempt to hint that this artifact is being managed in the current effective pom. Note: effective pom is only calculated when the pom file is saved. So any unsaved changes will not be taken into account.

To make it really easy for you to pick the managed artifact, the top node (ant ant-antlr) represents the managed version in this case (otherwise it's the latest version). So you don't have to drill down to the list of version to select the managed one. Just go with the artifact's top node.

If you find any issues with this feature or have a great idea for improvement, please don't hesitate to file an issue in the bugzilla. We look forward to your feedback.

Written by Milos Kleint