How to activate multiple profiles in maven

Profiles are specified in pom. Profiles modify the POM at build time, and are used to give parameters different target environments for example, the path of the database server in the development, testing, and production environments. In the following example, we will attach maven-antrun-plugin:run goal to test the phase. This will allow us to echo text messages for different profiles. We will be using pom. Now open the command console, go to the folder containing pom.

Pass the profile name as argument using -P option. Add another profile element to profiles element of pom. Pass the profile names as argument using -P option.

Open Maven settings. If settings. Since these profiles are specified inline, and therefore have a better chance of preserving portability, it's reasonable to say you can add more information to them without the risk of that information being unavailable to other users. We don't allow modification of some POM elements outside of POM-profiles because these runtime modifications will not be distributed when the POM is deployed to the repository system, making that person's build of that project completely unique from others.

While you can do this to some extent with the options given for external profiles, the danger is limited. External files such as settings. Let us take this scenario for elaboration. When the effective POM get deployed to a remote repository, any person can pickup its info out of the repository and use it to build a Maven project directly.

Now, imagine that if we can set profiles in dependencies, which is very important to a build, or in any other elements outside POM-profiles in settings. And we have to also think about how to share the settings. Note that too many files to configure is very confusing and very hard to maintain.

Bottom line is that since this is build data, it should be in the POM. One of the goals in Maven 2 is to consolidate all the information needed to run a build into a single file, or file hierarchy which is the POM. All profile elements in a POM from active profiles overwrite the global elements with the same name of the POM or extend those in case of collections.

In case multiple profiles are active in the same POM or external file, the ones which are defined later take precedence over the ones defined earlier independent of their profile id and activation order. We've already mentioned the fact that adding profiles to your build has the potential to break portability for your project.

We've even gone so far as to highlight circumstances where profiles are likely to break project portability. However, it's worth reiterating those points as part of a more coherent discussion about some pitfalls to avoid when using profiles. There are two main problem areas to keep in mind when using profiles. First are external properties, usually used in plugin configurations. These pose the risk of breaking portability in your project. The other, more subtle area is the incomplete specification of a natural set of profiles.

External property definition concerns any property value defined outside the pom. The most obvious usage of properties in the POM is in plugin configuration. While it is certainly possible to break project portability without properties, these critters can have subtle effects that cause builds to fail.

For example, specifying appserver paths in a profile that is specified in the settings. Consider the following pom. When you build the integration-test lifecycle phase, your integration tests pass, since the path you've provided allows the test plugin to install and test this web application. Congratulations, your project is now non-portable.

Inlining this profile in your pom. Another, less attractive answer might be standardization of development environments. However, this will tend to compromise the productivity gain that Maven is capable of providing. In addition to the above portability-breaker, it's easy to fail to cover all cases with your profiles.

When you do this, you're usually leaving one of your target environments high and dry. Let's take the example pom. Now, consider the following profile, which would be specified inline in the pom. So, executing:. And when we execute. However, executing:. We haven't considered the case for the production environment when writing our profiles. The incomplete specification of this natural set means we have effectively limited our valid target environments to the development environment.

Your teammates - and probably your manager - will not see the humor in this. Select the appropriate checkboxes to activate the profiles you need. You can have several active profiles. When they are activated, their configurations are merged based on the POM profile declaration. You can also activate profiles automatically according to a range of contextual conditions for example, JDK version, OS name and version, presence or absence of a specific file or property, but you still need to specify all the parameters inside your POM.

For more information, refer to Maven profiles. You can manually de-activate this profile by clicking the checkbox. Also note that if you manually activate any other profile, the activeByDefault profile will be de-activated.