Thursday, November 6, 2008

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 (
  • 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, jrubygroovy 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.


Diggy's Boy said...
This comment has been removed by the author.
AmitArtist said...
This comment has been removed by the author.
AmitArtist said...

Very helpful