As we saw in the previous chapters, Maven isn't a monolithic self-standing product. Instead, it is a pluggable and evolving tool. The sake of extensibility is achieved through the Maven plugin system.
The need for extensibility comes from the nature of the environment Maven operates in. The need for flexibility comes from a vast community of users with different exigencies for their products producing different applications.
Plugins extend Maven's core functionality, allowing it to accomplish many custom tasks. In the previous chapter, we used plugins to build modules with different packaging used as common product distributions (WAR, EAR, EJB). Other plugins make possible custom packaging for autoexecutable products (executable JAR), generating web service implementations based on XSD or WSDL definition, and many other functionalities.
Most of the plugins are developed by Apache. Despite that, everyone can develop their own plugin to fit their needs. A plugin could cover specific project requirements or simply extend the execution of an operation to different lifecycle phases.
In this chapter, we will learn about the following topics:
- Writing a simple Maven plugin
- How to test our plugin
- How to publish your plugin in a local repository
Thanks to maven-plugin-plugin, we can use many different programming languages in order to build an executable Maven plugin. It supports different programming languages such as Java, C#, Ruby/JRuby, Scala, Groovy, and Ant. On the other hand, maven-plugin-testing-harness provides unit test and integration functionalities.
A common issue that many developers face is release policies. Often, companies impose to trace every step of every project release.
Projects are composed of many modules, and for each of these modules we have to trace its history. In order to declare a module as released, we have to trace which issues were resolved in that release, and how many issues remain open.
For issue tracking and management, we hosted an instance of Mantis bug tracker in a private server. All issue information is stored in a MySQL database instance.
Tip
You can find more information on Mantis here: http://www.mantisbt.org/.
The version of the project model differs from the Mantis version of a module. In order to fill this gap, we created an XML file named release_structure.xml and stored it in the ${basedir} folder of each versioned module.
In this file, we store information about the actual production version of the module. The release structure is updated every time a new module version is released. If the project's version is not specified, the actual project.version value is used.
In order to resolve this automation problem, we implemented a plugin named mantis-maven-plugin. Whenever a build is performed, our plugin queries for the release version of the project ID passed through configurations. Once it resolves the project, it gets all the resolved issues related to the project, and marks them as released in that build version.
Our plugin performs all these operations by means of the release_structure.xml file.
Starting from this problem, we can explain how to build a custom plugin.