Maven only downloads most of these dependencies because you’ve added them to your project. If you are unhappy that Maven is “downloading the internet” then stop developing software that depends on external libraries. Easy, right? Stop using Spring and Hibernate, stop referencing the commons libraries, and do everything yourself. This would be one way to avoid downloading any artifacts from a remote repository. Stop using Maven to build your software and write your own build tool that has all of the capabilities of Maven and every imaginable Maven plugin baked into it.

Not a workable solution, right? The fact of the matter is that your software has dependencies on external libraries. If you find yourself constantly “downloading the internet” there’s a reason. You are depending on projects that depend on “the internet” or, your projects have a very wide set of dependencies that may need to be trimmed.

How can we avoid creating projects and POMs that “download the internet”? The simple answer is that everyone needs to start focusing on dependencies. Library developers need to be smarter about creating leaner, meaner dependency lists, and you need to start evaluating your own dependencies with an eye on efficiency.

Library Developers Need to Modularize

Take a project like Spring as an example. Spring’s libraries provide interoperability across a number of core enterprise APIs: JMS, JDBC, JTA. Spring also allows people to plug-in different implementations for various feature: Hibernate, ehcache, MyBatis, log4j, slf4j, etc. Picking on Spring in particular, artifacts from Spring tend to rely on the world. If you use some of the core Spring libraries you’ll soon realize that that one simple dependency XML snippet actually translates to 30 or 40 dependencies.

If you are creating a library (Spring, Guice, or Hibernate) you need to start thinking about the dependencies that you are selecting. Instead of just blindly adding in a dependency to ten artifacts, split up your projects so you don’t create that one, gigantic library which depends on the world. I’ll bring the conversation back to Spring. Spring is moving in the right direction, the most recent version of spring-core version 3 has five dependencies, while spring-core 2.5.6 has 13 dependencies. If you’ve watched the progression of the Spring libraries over time, you’ll notice a trend toward modularization. Take the Spring AWS as an example – there isn’t just one spring-aws library, there is a spring-aws-ant, spring-aws-ivy, spring-aws-maven library. As more people within the Springsource use Maven as a build tool, more people are starting to realize the value of having more projects with lighter POMs.

This matters because low-level, almost universal libraries like Spring, Hibernate, log4j, Guice, Commons libraries. These projects end up putting dependencies into everyone’s classpath. If developers of popular libraries get the message and move toward more modular project scopes then you shouldn’t see so much bloat in your own project’s classpaths.

Don’t just let any dependency into your project

What can you do? You need to have some standards. Don’t just let anybody put some new dependency into your POM. Have some process to evaluate and assess exactly what a new dependency is going to do to your classpath. Is that new-fangled database library going to drop a dependency bomb and pull in 20 other libraries, some of which have incompatible licenses?

One tool you can use to make this process easier is Nexus Professional. Nexus Professional has a new Maven Dependency report. It is very easy to use, find an artifact in Nexus Professional, and then select the Maven Dependencies tab. This report will allow you to see just how many dependencies a particular artifact is going to introduce into your project. It will also list artifacts that may be missing from the public repositories, giving you a chance to assess the quality of an artifact’s dependencies.

The screenshot below shows options that are available to you by hovering over on an expression in the m2eclipse POM XML Editor.

When hovering your mouse on top of a managed dependency, we show the currently resolved version of the artifact (dependency or plugin) and also where the artifact is managed (the model’s coordinates).

Invoking a hyperlink on the managed artifact gives you some new options as well. If the location is in another pom.xml file, that POM file is opened for you, and the cursor is placed at the location of the artifact’s definition.

Next to the preexisting option to open the artifact’s POM, you can now also navigate to the location where the artifact is managed. Let’s see where it leads us.

As you can see the artifact’s managed location is using an expression for declaring the version. Here you can again hover your mouse over the expression to see what it resolves to in the effective POM. To get to the definition of the property, just invoke the hyperlink again (Ctrl-Left Click on most platforms, Cmd-Left Click on MacOSX). See the next screenshot.

After hyperlinking, you reach the definition of the antlr.version property and you can finally change the property value and upgrade your ant-antlr dependency. 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 eclipse.org bugzilla.

These improvements will be available from the Indigo repository at the end of this week as part of the M5 release. If you are adventurous you can try the temporary Hudson build which can be found here.

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 eclipse.org bugzilla.   We look forward to your feedback.

Not knowing the details of this merge process naturally leads to some confusion about why an effective configuration looks the way it looks, or why changes to some parent POM’s configuration don’t have the desired effects in child POMs.

This post attempts to shed some light on this confusion, and provides you with a sense of how Maven merges plugin configuration from multiple sources.   This post uses attributes which are available in Maven 3.0.2.

The Simplest Case: Merging Parent and Child POMs

As a concrete example, let’s assume we have a parent POM with the following plugin configuration:

Let’s further assume we have a child POM that inherits from the above parent and that specifies the following configuration for the same plugin:

Now, as an invocation of mvn help:effective-pom will show you, the effective plugin configuration for the child project will be:

This result demonstrates the default merge behavior. The configuration elements are recursively merged based on the element name, and elements from the parent POM are only added to the result when the child POM does not contain an equally named element. Let me stress that merging of plugin configuration is purely an operation on the XML DOM tree. In particular, the merge process has no knowledge of the actual data structures in the plugin that will be configured nor their semantics. In other words, configuration values are generally not considered as merge keys when combining child and parent elements, only the name of the configuration elements is used to identify conflicting elements that need to be merged.

Controlling the Merge Process with combine.children and combine.self

Sometimes the default merge behavior doesn’t produce the intended configuration. In this case, one can use two attributes on the child configuration to adjust the behavior as shown in the next child POM:

Assuming the above child POM still inherits from the previously sketched parent POM, one would now get the following effective configuration:

As you can see here, usage of combine.children="append" results in the concatenation of parent and child elements, in that order. The attribute combine.self="override" on the other hand completely suppresses parent configuration to be inherited. That said, it’s senseless to specify both combine.self="override" and combine.children="append" for a configuration element, the former directive takes precedence.

Note that these attributes only apply to the configuration element they are declared on, and are not propagated to nested elements. That is if the <item> element from our last child POM would be a complex structure instead of a mere string, its sub elements would still be subject to the default merge strategy.

The combine.* attributes are however inherited along a hierarchy of POMs. So some care must be taken when adding those attributes to a configuration snippet in a parent POM as this might affect child or grand-child POMs unless those explicitly override the attributes themselves.

Last but not least, please note that the attributes described here to control merging only apply to plugin configuration. You cannot use these attributes on other elements of the POM.

Sonatype Training

You’ve completed Maven 101, learned about the Maven lifecycle, Maven plugins, goals and projects, all about the contents of the Project Object Model (POM) – so what’s next?

For those wanting to dive even deeper into Maven, Sonatype is offering an online training course, Maven 201: Development Infrastructure Design.

Maven 201 covers advanced topics such as:

• Advanced multimodule project architecture
• Enforcing standards with the Enforcer plugin
• Installing and configuring a repository manager
• Installing and configuring a continuous integration server

At the end of this training course, you will have advanced familiarity with the structure of a Maven POM and a Maven multi-module project.

Next training course:

• MVN-201
• January 20 & 21, 2011
• 11:00 am – 4:00 pm EST (GMT – 05:00)
• Enroll today

JAXenter

The primary goal is a way forward for all Maven users, efficient embedding, increased performance, synchronizing the Maven 3.0 code base with m2eclipse, and adding extension points for tools like Tycho, Polyglot Maven, and the Maven Shell.

To read the full JAXenter interview, click here.

Scope, Architecture, and Conventions

Our goal is to create a swap-in replacement for Plexus built on top of Guice. Ideally this should be done without changing the core Guice code, but if this is not possible then any fixes or new functionality should be written up and reported on the Guice issues page. While there is no guarantee that these changes will make it into an official Guice release, improvements that benefit a wider audience should have a better chance of making it into Guice.

Sonatype currently maintains a patched build of Guice trunk with the following major patches:

• Provide access to Guice’s own internal TypeConverters
• BytecodeGen and related AOP / bridge classloader fixes

This build also contains some experimental changes which have not yet been written up because they are still being tested:

• ability to turn off validation error about using @Singleton on an interface instead of an implementation class
• ability to turn off creation of parent JIT bindings when using child injectors (simplified version of this issue)

Guice/Plexus Integration Module Architecture

The solution is separated into re-usable, pluggable modules that together provide a replacement for the existing Plexus container. There is also an artifact that combines these modules into a single JAR, as this would make it easier to swap between the old and new container. Each module has a specific responsibility and any dependencies between modules is kept at a minimum. The following is a list of the components or modules that comprise the Guice/Plexus integration project.

guice-bean-inject

Extends Guice to support customized injection of named properties (fields and setter methods).

guice-bean-reflect

Provides utility methods and support code for reflection, bean properties, and resource scanning.

guice-plexus-metadata

Shared metadata interfaces, runtime implementations of Plexus annotations, and collection adapters.

guice-plexus-scanners

Annotation and XML scanners that provide metadata about components, requirements, and configuration.

guice-plexus-converters

Standard Plexus type conversion rules that can create instances from simple strings and XML markup.

guice-plexus-locators

Guice based registry that can locate components of a certain type, optionally ordered by name hints.

guice-plexus-bindings

Guice module that uses: scanners to find and bind Plexus component beans, converters to turn configurations into instances, and locators to find components based on requirements. This component also provides a simple lifecycle management API.

guice-plexus-shim

Creates an injector with Plexus bean support, adds Plexus lifecycles, and provides the container API.

A Brief introduction to Guice and JSR330

Guice is a Dependency Injection framework that injects constructors, methods, and fields annotated with @Inject. Guice recognizes both the JSR 330 and the original Guice form of this annotation.

Every injection point (constructor, method, or field) has a number of dependencies, each one represented by a key: the type to be injected plus an optional qualifier annotation that lets you choose between different implementations of the same type. For example:

public class Car {
   // Injectable constructor
   @Inject public Car(Engine engine) { ... }

   // Injectable field
   @Inject @Named("Corinthian Leather") private Seat seat;

   // Injectable package-private method
   @Inject void install(Windshield windshield, Trunk trunk) { ... }
}

Has the following injection points and dependency keys:

Constructor      ---> Key[ Engine ]
Field "seat"     ---> Key[ Seat, @Named( "Corinthian Leather" ) ]
Method "install" ---> Key[ Windshield ], Key[ Trunk ]

The Guice injector maintains a set of bindings that map dependency keys to providers that supply instances of the key type. These providers may use different strategies to supply instances: per-lookup, singleton, per-conversation, even your own custom strategies.

When you configure Guice you are registering bindings from one key to another, or between keys and providers:

// Key[ Seat ] ---> Key[ FoamSeatImpl ]
bind( Seat.class ).to( FoamSeatImpl.class );

// Key[ Seat, @Named( "Corinthian Leather" ) ] ---> Key[ LeatherSeatImpl ]
bind( Seat.class ).annotatedWith( Names.named( "Corinthian Leather" ) ).to( LeatherSeatImpl.class );

// Key[ Engine ] ---> Key[ V8EngineImpl ]
bind( Engine.class ).to( V8EngineImpl.class );

// Key[ V8EngineImpl ] ---> Provider[ V8EngineImpl, "singleton" ]
bind( V8EngineImpl.class ).in( Singleton.class );

// Key[ Windshield ] ---> Provider[ Windshield, "custom" ]
bind( Windshield.class ).toProvider( WindshieldProvider.class );

// Key[ Trunk ] ---> Provider[ TrunkImpl, "constant" ]
bind( Trunk.class ).toInstance( new TrunkImpl() );

The injector can also create certain types of bindings on-demand when no such explicit binding already exists, such as:

// Key[ FoamSeatImpl ] ---> Provider[ FoamSeatImpl , "per-lookup" ]
// Key[ LeatherSeatImpl] ---> Provider[ LeatherSeatImpl, "per-lookup" ]

The Key[...] and Provider[...] markup is pseudo-code

So far so good, but what if you have classes that don’t mark dependencies with @Inject? What if they’re identified in XML or marked with custom annotations like @Requirement or @Configuration?

TypeListeners, MembersInjectors, and InjectionListeners

Since 2.0 Guice has provided a way to supplement the core injection process with your own custom injections. Here’s what you need to do:

1. Register your custom TypeListener, using a Matcher to filter the specific types you are interested in, or Matchers.any() if you want to process all types
2. Guice will call your TypeListener once for each type that matches your chosen matcher, passing you a TypeEncounter
3. You can then analyze the type to be injected, prepare any custom injection data, and use the TypeEncounter to register aMembersInjector or InjectionListener for this type. Because the TypeListener is called per-type, and not per-instance, you should try to do as much preparation work here as possible to avoid spending too much time in the MembersInjector or InjectionListener
4. Guice will call your MembersInjector once for each instance it injects, after it has performed the core injection. You can then use the data prepared by your TypeListener to perform any custom injection
5. Finally Guice will call your InjectionListener once for each instance it injects, after all injections are complete. This is where you can hook in management code, such as start and stop life-cycle support

You’ll notice that Guice does not dictate how each type should be scanned or prepared for custom injection. While Guice does provide utility methods that can tell you which class members are annotated with @Inject, there’s no general-purpose mechanism to scan class members looking for custom annotations. On the one hand this is good, because it avoids bloating the core JAR with code you might not need. But on the other hand each custom injection client could end up implementing similar scanning code again and again. The recommended approach is to put optional code like this in an extension library that people can use if they need to, rather than keep folding it into the core.

We’re going to use custom injection to support Plexus components whose dependencies may be annotated or configured in XML. Plexus components are similar to Java beans in that they can have fields or setter methods, so rather than write a custom injector that’s closely tied to Plexus let’s see if we can develop an extension library for “beans” in general. That way we can build support for Plexus on top of it, and allow people to re-use it for other bean-style injections.