Maven: Customize web.xml of web-app project

Question

I have a web application Maven project, and I want to customize the web.xml file depending on the Profile that is running. I am using the Maven-War-plugin, which allows me to define a "resources" directory, where the files may be filtered. However, filtering alone is not sufficient for me.

In more detail, I want to include (or exclude) the whole section on security, depending on the profile I an running. This is the part:

....
....

<security-constraint>

    <web-resource-collection>
        <web-resource-name>protected</web-resource-name>
        <url-pattern>/pages/*.xhtml</url-pattern>
        <url-pattern>/pages/*.jsp</url-pattern>
    </web-resource-collection>

    <auth-constraint>
        <role-name>*</role-name>
    </auth-constraint>

    </security-constraint>
        <login-config>
        <auth-method>${web.modules.auth.type}</auth-method>
        <realm-name>MyRealm</realm-name>
    </login-config>

<security-constraint>

....
....

If this is not done easily, is there a way to have two web.xml files and select the appropriate one depending on the profile?

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.

View more solutions

Comments

[Philihp Busby]

I actually prefer this way. It's not ugly, and with different web.xml files, I could see a situation where someone made a change to the development web.xml, and it worked, then built with production's web.xml, deployed, and the site went down.

[Philihp Busby]

I had to wrap the property in <![CDATA[ ... ]]> in order for this to work.

[Brian M. Carr]

since people keep helpfully editing the original (hint, the &gt; is a part of the solution!!!!), note that the above will not work out of the box. I've already fixed it, but people keep changing it back...

[Ryan Beesley]

I used a similar technique. Instead of using comment start and end nodes, I created a commented macro like <security-constraint><!--${dev.security.constraint}-->...</s‌​ecurity-constraint>. Because it was commented out, it is still a valid XML document. In my dev profile I had <profile><id>dev</id><properties><dev.security.constraint>--‌​&gt;[Content goes here]&lt;</dev.security.constraint><properties></profile>. This means that if I don't define dev.security.constraint, it is becomes a harmless comment, but when it is defined, it is the content sandwiched between two empty comments.

[april26]

I'd do more than +1 for this solution if I could. Very nice!

[rwyland]

I like the idea of this, except for the invalid XML errors which are resolved by @ajozwik answer below. +1 for heading in the right direction though!

[John Manko]

Is this solution possible when building an EAR? Say I have a maven project with two EAR sub projects, and each include the same WAR, but require different web.xml. web-fragment.xml doesn't work with EAR/lib packaging. See stackoverflow.com/questions/48390170/…

[Nikola]

So hacky but i love it

[Pieter De Bie]

Is it maven.war.webxml or webXmlPath? Your start tag is different from the closing tag.

[claudiobosticco]

I'm using this approach, but sometimes, not everytime, in the web.xml it remains the escaped string, ie --&gt;, instead of -->. Same if I use cdata. maven-war-plugin 3.2.0