More Maven Best Practices @ ApacheCon by Brett Porter

Here are my notes from Brett's talk about Maven.

More Apache Maven Best Practices, by Brett Porter General Principles from last years presentation

• Set up your environment in advance
• A repository manager is a must (e.g. Archiva)
• Keep your POM simple, write your build like you write code
• Keep the build portable
• Avoid hard coding
• Make artifacts portable and minimize resource filtering 
• Keep db config out of the project 
• Make sure the build is reproducible
• Lock down versions, lock down environmental variations (don't rely on getting the latest, use version numbers)
• Use the Enforcer plugin (http://maven.apache.org/plugins/maven-enforcer-plugin/)
• Use this plugin to ensure other modules do not use automatic versions like latest and latestRelease
• Release your project early and often

Dependency Management

• Transitive dependencies are a big part of Maven, however sometimes dependencies get messed up, use mvn dependency:tree to analyze your dependencies. 
• Use enforcer plugin to ban specific dependencies and then you can use global exclusions to keep that dependency out of the project
• Specify only what you need, specify scope, USE dependencyManagement
• Use dependency:analyze, find out what you're using but not declaring, find out what you're declaring but not using

Integration Testing

• Unfortunately, an afterthought in Maven 2.0.x, at least in lifecycle
• Tests in a separate module, tests in same project, you'll most likely need to use profiles
• In Maven, plugin ITs are in the project
• Using a separate project, most common pattern in Maven. If you're testing multiple modules put tests in another module
• create a parallel module, use the regular src/test/java directory, add a dependency on the module being tested, you will typically put this in a profile to control when it's run (e.g. in your CI env)
• If you are testing in the same project (e.g. a plugin or framework example), use another source dir, like src/it or use the src/test/java path and exclude a package from the general test so they can be used during integration testing (this is the easiest approach)

Maven sites and reporting

• There are two technologies working here, reporting and rendering, they are not the same thing!
• Site tips, avoid reports and documentation sites, some minimal project reports, like mailing lists, source repository may be relevant
• use site inheritance, just like in your pom, you can break down the site.xml file, they sit along side your pom.xml file
• Use versioning in the URL
• Include release notes in the versioned usage documentation
• Report tips
• Set up what you'll use! Don't create reports with thousands of issues
• It won't be used if, too much information or there is irrelevant information
• Don't settle for the default settings
• Use active checks, not passive reports, fail the build
• Use profiles to control reports, you don't need to run the reports all the time

Plugin Development

• Sometimes it is easier to use a script for short, one-off, customizations, e.g. antrun plugin, jruby, groovy plugin, etc.
• If you might use it twice, consider writing a plugin
• Writing a plugin isn't a big deal, you can write it in Java, Ruby, Groovy, etc.
• Write your functionality in components, with the Mojo as a "wrapper"
• Minimize Maven API dependencies and component exposure, e.g. use maven-artifact, not maven-core (be aware of your dependencies, only use what you need)
• Do as we say, not as we do. Maven fails to implement many of these practices in various projects. Maven commiters learned the hard way!

You can get Brett's slides here.