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