Demo Content

Code provided here demoes one specific type of extension: Maven 3 lifecycle extension, and the different results obtained when injecting this extension in the different ways available.

Maven lifecycle participation can be provided through 3 APIs:

1. org.apache.maven.execution.AbstractExecutionListener object, instantiated and added to listeners like Maven CLI does using internal eventSpyDispatcher.chainListener(executionListener) API (source) or copying the small implementation,
2. org.apache.maven.AbstractMavenLifecycleParticipant Plexus/Sisu/JSR-330 component,
3. org.apache.maven.eventspy.AbstractEventSpy Plexus/Sisu/JSR-330 component.

This study implements each API (see javadoc) then tests implementations in ITs that configure the extension in different ways: verification done after IT execution checks expected differences (see ITs results).

Classical Types of Core Extensions

A Maven core extension is a library that goes into Maven Core classloader, then is really in the core execution of Maven, unlike a plugin that runs in a child classloader separated from other plugins.

There are multiple reasons one wants to put his code in Maven Core classloader:

• add a Wagon protocol,
• override a component of Maven core, to change its behaviour (expertise required...),
• inject a lifecycle participant.

Configuring Maven Core Extensions

There are multiple methods available to declare a library as an extension:

1. classical POM's project.build.extensions.extension (since Maven 2),
2. put jars in Maven ${maven.home}/lib (since Maven 2) or ${maven.home}/lib/ext (since Maven 3),
3. use -Dmaven.ext.class.path=[path to files] (since Maven 3.0.2, see MNG-4936),
4. configure in .mvn/extensions.xml (since Maven 3.3.1)

Declaring an extension in POM is the most classical and flexible way to do: the only drawback is that the extension is activated after POM reading, which can be too late for some very specific use cases like EventSpy.

Installing an extension directly inside Maven installation avoids the previous limitation, but is not flexible.

-Dmaven.ext.class.path=[path to files] is a little bit more flexible, but remains not configured into the build, which is not suitable to ensure an extension is available at build time.

.mvn/extensions.xml is the ultimate solution for these use cases. Its only drawback is that it has been added only in Maven 3.3.1.

References

• Guide to Maven Classloading
• Example: Using Maven 3 lifecycle extension
• Guide: Using Extensions