How to define a named set of related dependencies in Maven?

Question

I have several independent projects (they don't have the same parent) but they use the same set of libraries. For example

• Project A
• Project B
• Project C

All these projects use Spring, Postgres, Hibrenate and tomcat. What I want to do is introduce the concept of a named collection of dependecies somethnig along the following lines:

• TSHP 1.0 - Might consist of tomcat 6.0.35, Spring 3.0.7, Hibernate 3.6.8 ... etc
• TSHP 2.0 - Might consist of tomcat 7.0.32, Spring 3.1.2, Hibernate 4.1.7 .. etc

I want to be able to say something like Project A depends on TSHP 1.0, Project B depends on TSHP 2.0 ... etc. The value I see for this type of setup is

• It is easy to standardize on a set of common libraries that are used as a group with a company, so auditing across projects is easy, you don't have to dig into a project's pom to see what is there if you know that it is using a named group of dependencies
• Starting a new project with the standard classpath could very easy because It should be possible to just include a single dependency on the named group and get everything that is needed for that type of application, only one person needs to figure out and verify that the combination of jars in the named class-path really works well with each other.

Can this type of setup be done with maven3? If so How?

Update: The problem I see with the parent pom setup is that there can only be one parent for a POM, but I might have several standard named class-paths, for example:

• WEB_SECURITY - might be a collection of jars that are used to protect against common web security issues, so an web app might include TSHP + WEB_SECURITY while a batch app might only include TSHP. Composition is better than inheritance and is much more flexible.

Answer 1

Create a new project for the 'platform', i.e. the group of dependencies that you want to use together. Its packaging type should be: pom.

<project>
    <groupId>…</groupId>
    <artifactId>tshp-platform</artifactId>
    <version>1.0</version>
    <packaging>pom</packaging>
    <dependencies>
      <!-- Dependencies for TSHP 1.0 -->
    </dependencies>
…

Release 1.0 of the the pom. Then update the version and dependencies for TSHP 2.0. Then release that.

Now your projects can simply declare a dependency on the pom project, and will pick up the platform transitively.

However, note that it's often considered good practice to explicitly declare artifacts that each individual project directly depends on. However, that's not essential.

Answer 2

I think what you are talking about is the concept of "Corporate POM".
The definition given by Sonatype is :

Corporate Pom

A Corporate Pom is a Parent Pom that sits at the top of an inheritance structure for a corporation. This is a recommended best practice for centralizing certain configuration such as Enforcer rule configuration, default Plugin versions, etc. This may also be called an “Organizational Pom.” The term “Super Pom” is often mis-applied to Corporate Poms.

See also :

Parent Pom

A parent pom is simply a pom from which other poms inherit via a section. Poms that inherit from a parent are sometimes referred to as “children” or “child poms.”