Maven plugins are debugged using the Java remote debugging mechanism. By using mvnDebug instead of mvn, a remote debugging session is started. It can be started by triggering a complete build or by invoking a specific goal, in both cases, over a project that uses the plugin.
Lets exemplify with the plugin built in the previous post. By executing the goal check-properties with mvnDebug, the execution will hang saying it is listening on a specific port:
mvnDebug org.softwaredistilled:properties-maven-plugin:1.0:check-properties -Dcheck="i18n_??"
Preparing to Execute Maven in Debug Mode
Listening for transport dt_socket at address: 8000
Another option would be to trigger a build like:
mvnDebug clean package
Preparing to Execute Maven in Debug Mode
Listening for transport dt_socket at address: 8000
Most of Java IDEs, if not all of them, provide some remote debugging tools. In Eclipse, a Remote Java Application debug configuration has to be created (Debug configuration section) that once started, it will stop at any break point.
The tricky part is that the plugin must be installed every time a modification is performed in order to see the changes at debugging time.
As any generic tool, Maven may require some customization. If this customization involves some actions not contemplated by the tool, then two approaches can be taken.
The first approach is to include some scripting in the pom file. By embedding ANT code, a lot of tasks can be achieved. Though it is a quick solution, it may turn the pom.xml file into an illegible and unmanageable file. Plus, it is difficult to reuse or share anything.
The second approach is to create a plugin with goals that perform the desired tasks.
A plugin can be thought as a bag of tasks or commands named goals. Each goal can be used during build time, to perform a specific job. In other words, a Maven plugin is the distribution mechanism for goals.
Building the plugin
It is very common in Java projects to use .properties files for internationalizing an application or for configuration purposes. It is also very common, to forget a key in one of the .properties files. So lets build a plugin with a goal that checks if a set of .properties files have all the same keys, at build time, to avoid discovering this error later.
The first step is to use an archetype for creating the plugin project:
mvn archetype:generate
-DarchetypeGroupId=org.apache.maven.archetypes
-DarchetypeArtifactId=maven-archetype-plugin
-DgroupId=org.softwaredistilled -DartifactId=properties-maven-plugin
As any archetype, this will create all folders and files, plus an example of a goal. Each goal will be handled by a Java class, named in the Maven world as Mojo (Maven Old Java Object).
The idea is to create a goal that receives a list of regular expressions indicating the .properties files to check. For instance, by setting the expression "i18n_??" it will validate if all files i18n_{language}.properties have the same keys.
