Maven: Customize web.xml of web-app project

Solution 1:

is there a way to have two web.xml files and select the appropriate one depending on the profile?

Yes, within each profile you can add a configuration of the maven-war-plugin and configure each to point at a different web.xml.

<profiles>
    <profile>
        <id>profile1</id>
        <build>
            <plugins>
                <plugin>
                    <groupId>org.apache.maven.plugins</groupId>
                    <artifactId>maven-war-plugin</artifactId>
                    <configuration>
                        <webXml>/path/to/webXml1</webXml>
                    </configuration>
                </plugin>
                 ...

As an alternative to having to specify the maven-war-plugin configuration in each profile, you can supply a default configuration in the main section of the POM and then just override it for specific profiles.

Or to be even simpler, in the main <build><plugins> of your POM, use a property to refer to the webXml attribute and then just change it's value in different profiles

<properties>
    <webXmlPath>path/to/default/webXml</webXmlPath>
</properties>
<profiles>
    <profile>
        <id>profile1</id>
        <properties>
            <webXmlPath>path/to/custom/webXml</webXmlPath>
        </properties>
    </profile>
</profiles>
<build>
    <plugins>
        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-war-plugin</artifactId>
            <configuration>
                <webXml>${webXmlPath}</webXml>
            </configuration>
        </plugin>
        ...

Solution 2:

There's a third, compromise option which I implemented in my project. It keeps everything in one web.xml while still making both it and the pom.xml readable. In my case, I had a need to sometimes have security and sometimes have no security, depending on the environment.

So what I did was:

In the pom.xml, define two profiles (or however many you need). Within the profiles, include two properties. When you want security, you leave them empty, like this:

<enable.security.start></enable.security.start>
<enable.security.end></enable.security.end>

When you want to exclude all of the security, you define them as follows:

<enable.security.start>&lt;!--</enable.security.start>
<enable.security.end>--&gt;</enable.security.end>

Then, you have a single web.xml file with the following:

${enable.security.start}
<security-constraint>
  ...
  // all of the XML that you need, in a completely readable format
  ...
</login-config>  
${enable.security.end}

The pom.xml maven-war-plugin has to be configured to use filtering. Mine looks like this:

   <configuration>
      <webResources>
        <resource>
          <filtering>true</filtering>
          <directory>src/main/webapp</directory>
          <includes>
            <include>**/web.xml</include>
          </includes>
        </resource>
      </webResources>
      <warSourceDirectory>src/main/webapp</warSourceDirectory>
      <webXml>src/main/webapp/WEB-INF/web.xml</webXml>
      ...

So, basically, when you select the profile to include security, you get two extra CRLF's in your web.xml. When you select the profile to NOT include security, the XML is all still in the web.xml, but it's commented out so it gets ignored. I like this because you don't have to worry about keeping multiple files in sync, yet the XML is still readable (and it's in the web.xml file where people would naturally look for it).

Solution 3:

Comment to Chris Clark answer. You can reverse - so in development you do not want to have any constraints (security or jndi, other)

<!-- ${enable.security.end}
<security-constraint>
    ...
</security-constraint>


${enable.security.start} -->

So in development you have commented out section. But in production it will be translated to (with maven profile):

<!-- -->
<security-constraint>
    ...
</security-constraint>


<!-- -->

and commented section will be visible.

Solution 4:

"matt b" has already posted the answer that is the most maven way of doing it. It is the way I'd recommend doing it 99% of the time.

However, occasionally, your configuration file might be quite complicated, and it doesn't make much sense to duplicate the whole file for each environment when only one XML stanza differs. In these cases, you can abuse property filtering to accomplish your goal.

Warning, a very duct-tape-y solution follows, and will not be for the faint of heart:

In your pom.xml:

Attention StackOverflow Editors!!!!

The html entity escaping is a part of the solution. The solution will NOT work if you replace it all with greater-than and less-than signs. Please leave the answer as is...

<properties>
    <test.security.config>
        &lt;security-constraint&gt;
            &lt;web-resource-collection&gt;
                &lt;web-resource-name&gt;protected&lt;/web-resource-name&gt;
                &lt;url-pattern&gt;/pages/*.xhtml&lt;/url-pattern&gt;
                &lt;url-pattern&gt;/pages/*.jsp&lt;/url-pattern&gt;
            &lt;/web-resource-collection&gt;

            &lt;auth-constraint&gt;
                &lt;role-name&gt;*&lt;/role-name&gt;
            &lt;/auth-constraint&gt;

            &lt;/security-constraint&gt;
                &lt;login-config&gt;
                &lt;auth-method&gt;${web.modules.auth.type}&lt;/auth-method&gt;
                &lt;realm-name&gt;MyRealm&lt;/realm-name&gt;
            &lt;/login-config&gt;

        &lt;security-constraint&gt;
    </test.security.config>
</properties>

in your web.xml

....
${test.security.config}
....

Because non-existent properties evaluate to an empty string, your configurations which do not have this property set (or the property is an empty xml tag) will evaluate to a blank line here.

It's ugly, and the xml is hard to modify in this form. However, if your web.xml is complex and you pose a greater risk of 4-5 copies of the web.xml getting out of sync, this may be an approach that will work for you.

Solution 5:

A new configuration was added to maven-war-plugin in version 2.1-alpha-2. Its name is filteringDeploymentDescriptors and it does exacly what you want.

This works:

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-war-plugin</artifactId>
    <version>2.4</version>
    <configuration>
        <filteringDeploymentDescriptors>true</filteringDeploymentDescriptors>
    </configuration>
</plugin>

And this also works:

<properties>
    <maven.war.filteringDeploymentDescriptors>true</maven.war.filteringDeploymentDescriptors>
</properties>

More information is available in the official documentation of filteringDeploymentDescriptors.