Build profiles are an important concept for unifying configuration differences between different environments. They also should capture information across all aspects of the POM.

Design

General Objectives

• All profile information should be kept together to create a single view of it, rather than dispersing it throughout the POM
• Based on the design decisions below, the profile is a subset of a POM that is applied onto the current POM as a form of inheritence.
• Each profile has a globally unique identifier.

Multiple Profiles

Multiple profiles can be active simultaneously. Each profile selected is cumulative. This allows each profile to do specific things, and various combinations do not need to be created. There is no need for duplication or special inheritence of profiles.

...

Defining the profile of a dependency is not done in the dependency definition itself for the following reasons:

• previous goal to keep all profile information together
• same reason as for elimination of dependency properties - hard to manage over transitive dependencies, and awkward to specify more than one without making specification of just 1 verbose.

Proposed solution:

<profiles>
  <profile>
    <id>jdk-1.4</id>    <!-- Use the id of "default" if it is the profile to use when none is given -->
    <dependencies>
      <dependency>
        <groupId>bouncycastle</groupId>
        <artifactId>bouncycastle-provider</artifactId>
        <version>1.1.6-jdk14</version> <!-- The JDK portion may be part of the classifier instead (see other doc)
      </dependency>
      ...
    </dependencies>
    ...
  </profile>
  ...
</profiles>

...

The following elements will be supported by profile specifications in various locations (noted inline):

• build (pom.xml)
  • plugins
  • pluginManagement
• dependencies (pom.xml)
• dependencyManagement (pom.xml)
• distributionManagement (pom.xml)
• repositories (pom.xml, profiles.xml, settings.xml)
• pluginRepositories (pom.xml, profiles.xml, settings.xml)
• modules (pom.xml)
• reports (pom.xml)
• configuration (profiles.xml, settings.xml)

Note that build is included for the benefit of the plugin definitions, and that will bring along other elements such as finalName and outputDirectory. These can also be beneficial. One of the unexpected behaviours may be the ability to override sourceDirectory which will completely substitute a new tree. This is probably undesirable, and so may need to be forbidden by validation.

...

The requirements listed that there would need to be all of the following:

• per user
• per project
• global

Project based settings that apply to all users can be stored in pom.xml as previously shown.

...

These should take on a similar format, however is restricted to:

• repositories (which are added to the list in the POM)
• plugin repositories (As above)
• general configuration properties

General configuration properties are used instead of allowing plugin configuration to be given. This avoids a settings file circumventing a POM. For example, the following general configuration may be given:

...

These are some thoughts on additional features that may or may not be made available:

• m2 --display-profiles switch that will show all possible profiles from the pom, its parents, and transitive dependencies.
• features to disable transient profiles in a deployment/release scenario to ensure the build is pure.