Maven 2 & 3

do these two profiles have the same id? How is the profile in the POM triggered?

Can you provide a test case, so we know when this is fixed?

upgrading to blocker to make sure this is resolved before we release.

Heer's the profiles.xml:

<profilesXml>
  <profiles>
    <profile>
      <id>vmassol</id>
      <properties>
        <installDir>c:/apps/cargo-installs</installDir>
      </properties>
    </profile>
  </profiles>
  <activeProfiles>
    <activeProfile>vmassol</activeProfile>
  </activeProfiles>
</profilesXml>

Here's a portion of the pom.xml:

[...]
  <profiles>

    <profile>
      <id>jboss4x</id>
      <activation>
        <activeByDefault>true</activeByDefault>
      </activation>
      <properties>
        <containerId>jboss4x</containerId>
      </properties>
      <build>
        <plugins>
          <plugin>
            <groupId>org.codehaus.cargo</groupId>
            <artifactId>cargo-maven2-plugin</artifactId>
            <configuration>
              <container>
                <zipUrlInstaller>
                  <url>http://ovh.dl.sourceforge.net/sourceforge/jboss/jboss-4.0.2.zip</url>
                  <installDir>${installDir}</installDir>
                </zipUrlInstaller>
              </container>
            </configuration>
          </plugin>
        </plugins>
      </build>
    </profile>
[...]

if I type "mvn install" the jboss4x profile is not activated. Removing profiles.xml makes it work. Forcing it using -Pjboss4x makes it active too (as would be expected).

The above example is working as designed. The <activeByDefault/> element is meant to specify that this profile will be activated if no other profiles are active in the build. Therefore, specific activation of any profile will cause this one to be deactivated. The issue with using the logic that the profile should always be applied is this:

1. If it's always applied, why not put it in the POM?
2. If it's active-unless-deactivated, how do you deactivate it?

Changing this feature right now might not make a huge impact on the user community, but it would break backwards compatibility in the strictest sense. Also, it requires defining some mechanism for deactivating profiles. We have one undocumented feature for this, which is:

-P -jboss4x

which would explicitly deactivate the jboss4x profileId, but this is not well tested, and IMO is pretty specific...I'd say that we would need something akin to:

<deactivation>
<!-- stuff similar to the activation section -->
</deactivation>

where the user can specify conditions that will deactivate the profile. Alternately, we could add an element to simply invert the activation logic...meaning the profile is active by default if this element is set, but anything triggered in the activation section will DEACTIVATE the profile...

I dunno which way we should go with this, but my feeling is that it might have to wait for 2.1.

BTW, can't you add a secondary activation condition that will result in this profile being activated despite the outcome of <activeByDefault/> ? If you cannot, I'd consider that a bug.

Thanks John

> 1. If it's always applied, why not put it in the POM?

I fail to undestand this. The reason I have a profiles.xml file is because it contains user-specific properties that cannot be shared with other users. That's the rasion d'etre of profiles.xml, isn't it?

> 2. If it's active-unless-deactivated, how do you deactivate it?

I don't want to deactivate it. I want jboss4x to be the default profile so that there's always a container defined by default and I want to let the user define where the containers are installed.

Is that an invalid use case?

If it's valid, then how do I implement it? Or are you simply saying that such a use case (which I think it pretty common and simple) is not supported?

Alright, let's see if we can make <activeByDefault/> a little more intuitive. Since external profiles (from profiles.xml or settings.xml) may be injected at almost any time (especially those in settings.xml), we don't want them to factor into the calculation of whether "by default" is satisfied...in other words, we don't expect/want that external profiles will have an impact on whether a default profile is used or not. The only thing that should be able to suppress a profile that's active-by-default is another profile in the POM which has been activated, either explicitly or using some trigger.

Using this, your example can still have users supplying installation directories for containers in an external profile (though the settings.xml may be a better place for this...I dunno). When they specify an install dir through a profile, that will have no impact on the choice of container to be installed, which is specified by a set of profiles that are embedded in the POM. When the user triggers some other container, maybe by "-Dcontainer=orion" or something, then the default profile of "jboss4" will be suppressed in favor of the "orion" profile...both of these would be embedded in the POM.

I'm checking this change into SVN soon, and we can roll it back if need be. IT is it0102 for testing purposes. Let me know what you think.

I think that's a good idea as it'll allow reproductible builds (i.e. external profiles should not modify what's in pom.xml).

modified the calculation used in activating <activeByDefault/> profiles.

Was:

If ANY profile {embedded in POM, external} was activated by a means other than <activeByDefault/>, then all <activeByDefault/> triggers were suppressed.

Is:

If a profile that's embedded in POM is activated by a means other than <activeByDefault/>, then all <activeByDefault/> triggers are suppressed.

For example, if I have a profile in my settings.xml that injects a new repository, and that profile is in my <activeProfiles/> section in the settings.xml, it cannot influence whether or not an <activeByDefault/> profile is triggered in a build that I run. This should keep such local environmental factors from changing the build process.

NOTE: This represents a subtle change in behavior from < 2.0.3 releases. However, I believe the nature of this change will make <activeByDefault/> usage more intuitive, and fix behavior that would otherwise appear buggy.