Page History

...

• 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.

Naming Conventions

To help with consistency of IDs across projects, profile IDs should follow some conventions. These could be partially enforced if necessary.

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.

...

<activeProfiles>
  <activeProfile>jdk-1.4</activeProfile>
  <activeProfile>os-windows</activeProfile>
</activeProfiles>

Preset Profiles

...

Likewise, specifying profiles on the command line will override all of those from settings.xml as well as any predefined ones.

Profiles for Dependencies

...

Plugin configuration and management can also be specified in the profile. Definitions here will add to the existing lists and merge as appropriate. For consistency - it behaves identically to inheritence, however regardless of the <inherit> and @inheritByDefault flag, the plugins from the current pom are always inherited into the profile as conceptually for the user, it is just overlayed, not inherited.

<profile>
  <id>jdk-1.4</id>
  <build>
    <plugins>
      <groupId/>
      <artifactId/>
      <version/>
      <configuration>
        ...
      </configuration>
    </plugins>
  </build>
</profile>

...

Inheritence and Transitivity

A fundamental issue with profiles operating across different projects will be having well known profile IDs. Generally, they will be better known over inheritence, but this is more important than those over transitive dependencies. It is important to use the definitions from above.

Note that the profiles are inherited, but only in such a way as they are applied to a parent POM before the inheritence of the parent and child is performed, so the settings required are already present. This ensures the proper precedence occurs (child and its profiles win over the profile of a parent).

For this reason it is unimportant if the IDs of profiles match or not, unless they are to be specified on the command line.

Location of Profiles

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

...

The main drawback to this is that it requires some consistency of property naming - however this outways the problems of directly injecting plugin configuration from settings.

Preset Profiles

It should be possible to preset the activation of some profiles. Eg, JDK, OS, host and user profiles could all be made active based on the settings of the machine running the build. However, should any profiles be made active via settings.xml, this will override all of the existing ones, rather than add to them.

Likewise, specifying profiles on the command line will override all of those from settings.xml as well as any predefined ones.

This will be done by some special activation tags (the format of which is yet to be completely decided), for example:

<profile>
  <id>hsqldb</id>
  <activation>
    <property>hsqldb.enabled</property>
  </activation>
  <dependencies>
    <dependency>
      <groupId>hsqldb</groupId>
      .
      .
</profile>

<profile>
  <id>jdk-1.4+</id>
  <activation>
    <jdk>1.4+</jdk>
  </activation>
  <build>
    <pluginManagement>
      <plugin>
        <artifactId>maven-compiler-plugin</artifactId>
        <configuration>
          <source>1.4</source>
      .
      .
</profile>

Resource Filtering

Under the above design, filtering can simply be a configuration element on the resources plugin (as per Kenney's patch, already available). The profiles will allow the introduction of different filter sets.

...

The plexus use case requires that a different goal be bound to the lifecycle. However, this does not entail any changes to the lifecycle design with the above solution. Instead, the goals would simply be added to the <plugins> section as needed in each profile.

Outstanding Issues

The following issues still require some resolution:

...

.

Additional Features

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

...