0

I currently have a pom with platform specific profiles (e.g. linux 32bit, windows 64 bit, etc...). Additionally, I have set it up to automatically choose the invoker's platform as a default.

Now, assume I am in a linux 32 machine: I also want to build for win64 by invoking mvn -Pwin64 pakage but in doing so, both the linux32 and win64 profiles get activated. I have tried activating the local platform profile with activeProfiles and using ativation tags. The trouble is that -P does not disable all other profiles as explained in the documentation:

This option takes an argument that is a comma-delimited list of profile-ids to use. When this option is specified, no profiles other than those specified in the option argument will be activated.

Am I understanding this wrong? How would you handle this?

Note: I know I could run mvn -P-linux32,win64 but that is only valid on linux32 platforms, and any mistakes may result in a bloated build with duplicate classes.

Thanks!

Improve this question
4
  • you can add ! before a profile to unactivate a profie
    – yodamad
    Commented Oct 4, 2012 at 6:51
  • @yodamad thanks, yes, adding ! or - in front of the profile deactivates it, but, as I mention in the note, that is then specific to the system you run it in
    – Miquel
    Commented Oct 4, 2012 at 7:27
  • Can't you just mark all your profiles as deactivated by default ? (ok it forces you to precise which profile you target every time you launch a build, but at least you would'nt have to perform 'manual' deactivations when the target is different than the platform).
    – Yanflea
    Commented Oct 4, 2012 at 9:49
  • @Yanflea thanks! Yes, this is indeed my fallback solution. If possible, though, I'd rather give my developers a "reasonable default" (i.e. their platform)
    – Miquel
    Commented Oct 4, 2012 at 12:26

2 Answers 2

Reset to default
4

This statement from the profile docs:

As of Maven 3.0, profiles in the POM can also be activated based on properties from active profiles from the settings.xml.

Would lead me to try the solution below. Each developer defines his default platform as a property in his settings.xml file and overrides it on the cmdline if needed.

Developer's settings.xml

<profile>
    <id>platform-config</id>
    <property>
        <name>build.platform</name>
        <value>win32</value>
    </property>
</profile>
....
<activeProfiles>
    <activeProfile>platform-config</activeProfile>
</activeProfiles>

Project's pom.xml

<project>
...
<profiles>
    <profile>
        <id>win32</id>
        <activation>
            <property>
                <name>build.platform</name>
                <value>win32</value>
            </property>
        </activation>
        ...
    </profile>
    <profile>
        <id>linux32</id>
        <activation>
            <property>
                <name>build.platform</name>
                <value>linux32</value>
            </property>
        </activation>
        ...
    </profile>
</profiles>

Then, mvn install should activate the win32 profile because the default value for the build.platform property is win32, while mvn install -Dbuild.platform=linux32 will override the default property setting and use the Linux profile instead.

Improve this answer
5
  • I like this approach. If the problem is truly that each developer needs to build specific to their environment...that's what settings.xml is for. On your continuous integration server, you should specify the desired profile in the build command with -Pbuild.platform=<whatever>
    – noahlz
    Commented Oct 4, 2012 at 17:56
  • Aha! Now, this is a great idea. To be fair, it uses properties to work around the profile limitations, but Maven purity aside, this will certainly do the job nicely. Thanks so much!
    – Miquel
    Commented Oct 5, 2012 at 6:59
  • @noahz Agreed, this will work thanks a lot! Minor thing for future readers, in the Continuous integration server I suppose you meant -Dbuild.platform=<whatever>
    – Miquel
    Commented Oct 5, 2012 at 7:00
  • 1
    Actually, i meant -P<build.platform> - direct profile activation FTW
    – noahlz
    Commented Oct 5, 2012 at 9:08
  • 1
    @Miquel, I believe you are correct, if the build user has a default defined in settings.xml. The direct profile activation (with -P) will not deactivate the profile activated using the build.platform property in the settings.xml. Both will be active, which is what we hoped to avoid. It is necessary to redefine the property (-Dbuild.platform=newPlatform). @noahz way works if there is no default in the settings file.
    – user944849
    Commented Oct 5, 2012 at 13:09
0

Why don't you use the profile activation by plattform like this:

<project>
    ...
    <profiles>
        <profile>
            <id>win32</id>
            <activation>
                <activeByDefault>false</activeByDefault>
                <os>
                   <name>Windows XP</name>
                                <family>Windows</family>
                                <arch>x86</arch>
                                <version>5.1.2600</version>
                        </os>
            </activation>
            ...
        </profile>
    </profiles>
</project>
Improve this answer
1
  • Thanks for your answer. If I use this, as I understand it, no profile will be activated when I run mvn install is that right? The problem with that is that my developers will now be forced to explicitly write their platform as in mvn install -Pwin32. I think this wouldn't be different from removing the whole activation section from your example, or am I missing something?
    – Miquel
    Commented Oct 4, 2012 at 12:29

Not the answer you're looking for? Browse other questions tagged or ask your own question.