Optimizing and Refactoring POMs

来源:互联网 发布:组态软件哪个好 知乎 编辑:程序博客网 时间:2024/04/30 12:02

Optimizing and Refactoring POMs

节选自http://www.sonatype.com/books/maven-book/reference/optimizing.html

POM Cleanup
Optimizing Dependencies
Pull-up common dependencies to dependencyManagement
Use built-in project version and groupId for sibling projects
Optimizing Plugins

POM Cleanup

Optimizing a multimodule project’s POM is best done in several passes, as there are many areas to focus on. In general, we are looking for repetition within a POM and across the sibling POMs. When you are starting out, or when a project is still evolving rapidly, it is acceptable to duplicate some dependencies and plugin configurations here and there, but as the project matures and as the number of modules increases, you will want to take some time to refactor common dependencies and configuration points. Making your POMs more efficient will go a long way to helping you manage complexity as your project grows. Whenever there is duplication of some piece of information, there is usually a better way.

回页首

Optimizing Dependencies

Fortunately, dependency duplication and sibling dependency mismatch are easily preventable if you make some small changes. The first thing we’re going to do is find all the dependencies used in more than one project and move them up to the parent POM’s dependencyManagement section.

Once these are moved up, we need to remove the versions for these dependencies from each of the POMs; otherwise, they will override the dependencyManagement defined in the parent project.

Pull-up common dependencies to dependencyManagement

If more than one project depends on a specific dependency, you can list the dependency in dependencyManagement. The parent POM can contain a version and a set of exclusions; all the child POM needs to do to reference this dependency is use the groupId and artifactId. Child projects can omit the version and exclusions if the dependency is listed in dependencyManagement.

Use built-in project version and groupId for sibling projects

Use ${project.version} and ${project.groupId} when referring to a sibling project. Sibling projects almost always share the same groupId, and they almost always share the same release version. Using ${project.version} will help you avoid the sibling version mismatch problem discussed previously.

回页首

Optimizing Plugins

Unfortunately, dependencyManagement doesn’t apply to plugin dependencies, but we can still use a property to consolidate the versions. Most complex Maven multimodule projects tend to define all versions in the top-level POM. This top-level POM then becomes a focal point for changes that affect the entire project. Think of version numbers as string literals in a Java class; if you are constantly repeating a literal, you’ll likely want to make it a variable so that when it needs to be changed, you have to change it in only one place. Rolling up the version of HSQLDB into a property in the top-level POM yields the following properties element:

We can manage the plugin configuration in the top-level POM just as we managed the dependencies in the top-level POM with the dependencyManagement section. To do this, we use the pluginManagement element in the top-level POM’s build element:

回页首
原创粉丝点击