I’ve spent a lot of time recently writing or working on plugins for Maven recently. They’re simple, rewarding and fun to write.
I thought I’d share a couple of tips for making life easier when writing them.
Tip 1: Separate the Task from the Mojo
Initially you’ll put all the code for the mojo into the mojo’s class (i.e. the class that extends AbstractMojo). Instead think about separating the task out and having minimal shim code for the mojo. This will:
- Make it easier to unit test.
- Mean you can easily integrate with other tools, such as Ant.
- Make it easier to convert the simple data types in the mojo so more complex types for your task (e.g. turn a String into a File).
- Separate exception translation from the task.
Tip 2: Consider Externalizing Configuration
Normally you configure a plugin using theelement in the POM. This is fine for simple cases. When you have a large sets of configuration items, or where you might have several configuration profiles, this will result in long, hard to understand POMs. You can follow the assembly plugin’s example, have a standardised directory for putting config in, e.g. src/main/myplugin/config-profile-1.xml.
Tip 3: Match the Mojo to the Phase
Consider which phase you might want the mojo to run in. If it is doing things that ought to split accross phases, then split the mojo up and bind to the appropriate phase. It’ll make it easier to test and to maintain.
Tip 4: Don’t Repeat Time Consuming Work
Your mojo will get run multiple times on small variations of the same source code and config. Does it do a lot of intensive work every execution? I was working with a Mojo that unzipped a file every time it ran, by changing the zip code to only freshen files by checking file modification times, the task went from taking over a minute to execute to less than 10 seconds.
Tip 5: Plan Your Testing
Initially you’re probably writing your mojo and manually testing on the first project you’re going to use it on. This will be a long testing cycle, and result in an unreliable mojo. Separating the task from the mojo makes testing the task easy, but you’ll want to have some smoke tests for the mojo. Bugs in mojos can be hard for users to notice as there’s a tendency to assume most mojos are well tested and reliable.
Tip 6: Consider how you Provide Documentation and Help for your Mojo
IDEs and Maven can be a bit unhelpful here. What does that config item mean? Can I see an example? The solution is to provide a “help” mojo and optionally a Maven site. For example, if you execute “mvn assembly:help” or “mvn surefire:help -Ddetail=true -Dgoal=test” you’ll see help.
Reference: Tips for Writing Maven Plugins from our JCG partner Alex Collins at the Java, *NIX, testing, performance, e-gaming technology et al blog.Related Whitepaper:
Java Platform, Enterprise Edition is a widely used platform for enterprise server programming in the Java programming language.
This book covers exciting recipes on securing, tuning and extending enterprise applications using a Java EE 6 implementation.The book starts with the essential changes in Java EE 6. Then they will dive into the implementation of some of the new features of the JPA 2.0 specification, and look at implementing auditing for relational data stores.They will then look into how they can enable security for their software system using Java EE built-in features as well as using the well-known Spring Security framework. They will then look at recipes on testing various Java EE technologies including JPA, EJB, JSF, and Web services.Next they will explore various ways to extend a Java EE environment with the use of additional dynamic languages as well as frameworks.At the end of the book, they will cover managing enterprise application deployment and configuration, and recipes that will help you debug problems and enhance the performance of your applications.