Maven 2 & 3

Another idea is to add a new <always/> activation policy, as a nested element inside <activation>.

<always/> doesn't really have the same semantics, though...does it? When you specify <always/> it would seem to indicate to me that this profile will always be in effect to some measure. When you set a default profile, it means that profile will be activated if no others are, doesn't it?

What I really want to get at here is whether it makes sense to have a default profile, particularly now that you can specify:

<project>
...
<properties>
<someproperty>somevalue</someproperty>
</properties>
</project>

In the case of a default value for a property, this should suffice. Beyond that, having a default profile in settings.xml doesn't really make sense, since you can activate a profile using <activeProfiles/> in the settings.xml itself.

If you're using a profiles.xml, there may be a time when you need <always/> or <default/> or somesuch...I'll investigate adding both.

Another use-case if it helps..

I currently require the concept of a default profile in my project to control database configuration files. I have a default profile that pulls in a development db config and a live profile that uses a live db config. Without one of these specified the build will break, but obviously they're mutually exclusive so a default profile makes sense here.

POM properties would suffice if they could be overridden at the command-line, but I think it'd be nicer to be able to activate a non-default profile - e.g. "m2 install" for default, "m2 -Plive install" to use the 'live' profile rather than the default.

Actually, the profiles.xml also provides <activeProfiles/>. Checking that this is honored.

Added activeProfiles from profiles.xml to the mix as explicitly activated.

Use:

<project>
...

<properties>
<name>value</name>
</properties>
</project>

for defaults. These will be overridden by activated profiles and by child POMs.

reopening to adjust time.

Replying to Mark above:

Not sure I understand...you're talking about a development property set, versus a profile-driven one for the 'live' scenario, correct? Then what would happen if you specified the development information within the properties section just under the project root element, then used a profile in-line to activate the 'live' overrides, as such:

<project>
...
<properties>
<db.url>jdbc:hsqldb://path/to/some/file</db.url>
</properties>

<profiles>
<profile>
<id>live</id>
<activation>
<property><name>live</name></property>
</activation>

<properties>
<db.url>jdbc:oracle:...</db.url>
</properties>
</profile>
</profiles>
</project>

Does this solve your issue? I'll await your answer before re-closing this issue.

I'm currently using profiles to augment the normal build resources and configure plugins for deployment, for example:

<project>
...
<profiles>
<profile>
<id>default</id>
<activation>
<property>
<name>profile</name>
<value>default</value>
</property>
</activation>
<build>
<resources>
<resource>
<directory>src/profiles/default/resources</directory>
</resource>
</resources>
<plugins>
...
</plugins>
</build>
</profile>
<profile>
<id>live</id>
<activation>
<property>
<name>profile</name>
<value>live</value>
</property>
</activation>
<build>
<finalName>ROOT</finalName>
<resources>
<resource>
<directory>src/profiles/live/resources</directory>
</resource>
</resources>
<plugins>
...
</plugins>
</build>
</profile>
</profiles>
...
</project>

Ideally I'd remove the activation block for both in preference to using the -P switch at buildtime. Although of course one profile needs to activated, hence the need to specify a default profile. Does this make sense or do you see a better way of achieving this?

Oops, apologies - there were tabs in there!

Fair point. I'll put it in.

Added <activatedByDefault/> (boolean) to <activation/> section of a profile.

These will be activated when no others are...they should still be able to be activated by other mechanism, too. So:

<profile>
<id>test</id>
<activation>
<activatedByDefault>true</activatedByDefault>
</activation>

...
</profile>

I have included unit tests to check this behavior.

Actually the syntax needed is:

<profile>
<id>test</id>
<activation>
<activeByDefault>true</activeByDefault>
</activation>

...
</profile>

That is activeByDefault not, activatedByDefault.