Skip to end of metadata
Go to start of metadata

This proposal contains some suggestions for making profile activation and deactivation more powerful.

1. Allow multiple instances of each of the profile activators (MNG-1753, MNG-3328).

Currently each profile activator (property, os, jdk, etc) can only be specified for a single value. This limits the flexibility in many cases. For example, I may want to activate a certain profile for windows 2000 and windows xp, but not for any other versions of windows. If multiple os profile activators were allowed, the syntax for this would be very simple:

<profile>
  <activation>
    <os>
      <name>Windows 2000</name>
    </os>
    <os>
      <name>Windows XP</name>
    </os>
  </activation>
<profile>
2. Allow deactivation options similar to the activation options (MNG-3326).

In order to provide the most flexibility, it would be helpful to have deactivation options. For example, I may want to use a particular profile for every os except for windows 98. In this case, I

<profile>
  <activation>
    <activeByDefault>true</activeByDefault>
  </activation>
  <deactivation>
    <os>
      <name>Windows 98</name>
    </os>
  </deactivation>
</profile>

It is also worth noting that some of these negatives have already been implemented in somewhat non-obvious ways. For example, a property activator can use an exclamation point in it's value <value>!some-value</value> to accomplish something similar to profile deactivation. Also, the file operator also uses a <missing> tag to provide similar behaviour to a file deactivator.

3. Add the ability to group profiles together.

There are some cases where it is useful to define a group of mutually exclusive profiles. For example, there could be a suite of tests that need to run against one of serveral database configurations. It would be helpful if profiles could be grouped together so that only one profile of a given group can be active at a time, without affecting profiles in other groups. For example, in the following configuration, the mysql and dev-reports profiles are active by default. Activating the oracle profile would automatically deactivate the mysql profile but have no effect on the activation/deactivation of the dev-reports profile.

<profile>
  <id>mysql</id>
  <groupId>dbconfig</groupId>
  <activation>
    <activeByDefault>true</activeByDefault>
  </activation>
</profile>
<profile>
  <id>oracle</id>
  <groupId>dbconfig</groupId>
</profile>
<profile>
  <id>ms-sql</id>
  <groupId>dbconfig</groupId>
</profile>
<profile>
  <id>dev-reports</id>
  <activation>
    <activeByDefault>true</activeByDefault>
  </activation>
</profile>
  • No labels

5 Comments

  1. It would also be interesting for a profile to be marked as "exclusive" with another one.

    example :

    <profiles>
       <profile>
         <id>development</id>
       </profile>
       <profile>
         <id>release</id>
         <exclude>developement</exclude>
       </profile>
    </profiles>
    

    With this configuration, when the release profile gets enabled, it could either automagically desactivate the "developer" one, or warn and fail build if it is enabled.

  2. I think profile groups should be implicitly exclusive in terms of having exactly one profile active at any time. Why else would you group them? I'm also not too keen on having to explicitly exclude all other profiles with the activation of one...that's a much more verbose mechanism for exclusive profile grouping, which is what I think Paul is getting at in the proposal.

    Generally, I think Paul's approach above is pretty good, but there is one thing that leaves me a little uncomfortable: you have to scan all profiles to figure out what the membership of a profile group is. I started out here to suggest a new element called <profileGroups> that would provide the groupings, but the problem here is intuitively that doesn't mean that a profile can only belong to a single group in the same way that a groupId element does.

    I'm not sure how to solve the issue with extracting the membership of a profile group, but I think I like having a grouping element on each profile - with that being obvious that a profile can only belong to a single group - rather than the separate grouping section.

    One final thought: the element 'groupId' is part of an artifact coordinate throughout the rest of the POM (and maven in general)...we shouldn't overload that term in profiles. Maybe some other name like 'profileGroup' or even just 'group' would be better.

  3. Suggestion for profile groups : use java "dot syntax". For instance, you could have
    development, development.tests, development.reports and so on. Further allow the "*" : -Pdevelopment.* would activate all profiles of development. When specifying/defining a profile, always provide a fully qualified name.

  4. What about having the ability to activate profiles inside a profile?

    eg:

    <profile>

       <id>java6-mysql<id>

      <requires-profiles>

        <id>my-sql</id>

        <id>java-6</id>

      </requires-profiles>

    </profile>

    Been able to combine profiles like this would make the build definitions DRYer.

    I really like David Bernhard's idea for using dot notation for groups of profiles.

  5. Are these proposals still available?

    I particularly like the Erick Dovale one: in my case, I have several environments on which to deploy the same application. Unfortunately, two different OS are used on these environments. With the proposal above I could write:

    And so, I would not have to repeat OS specific properties and configuration in each related environment profile