Here are my notes from Brett's talk about Maven.
- 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
- 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
- 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)
- 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.
