Maven: customize web.xml of a web application project

I have a Maven web application project and I want to customize the web.xml file depending on the profile being run. I use the Maven-War plugin, which allows me to define a resource directory in which files can be filtered. However, filtering is not enough for me.

In more detail, I want to include (or exclude) the entire security section, depending on the profile that I run. This is that 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 choose the appropriate one depending on the profile?

+52
java web-applications maven-2 profile
Jul 21 2018-10-21T00:
source share
7 answers

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

Yes, in each profile you can add the maven-war-plugin configuration and configure each point to 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> ... 

Alternatively, you need to specify the maven-war-plugin configuration in each profile, you can specify the default configuration in the main POM section, and then simply override it for specific profiles.

Or, even simpler, basically the <build><plugins> your POM, use the property to refer to the webXml attribute, and then just change its 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> ... 
+73
Jul 21 '10 at 11:52
source share

There is a third, compromise option that I implemented in my project. It stores everything in one web.xml, while preserving both and readable pom.xml. In my case, I had a need sometimes to have security, and sometimes security, depending on the environment.

So what I did:

In pom.xml, define two profiles (or as many as you like). Inside profiles, two properties are included. When you need security, you leave them blank, for example:

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

If you want to exclude all security, you define them as follows:

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

Then you have one 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 mob-war-pom.xml plugin must be configured to use filtering. My 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 a profile to enable security, you get two additional CRLFs in your web.xml. When you select a profile to NOT include security, the XML is still in the web.xml file, but he commented on it, so it is ignored. I like it because you don't have to worry about synchronizing multiple files, but XML is still readable (and it is in the web.xml file, where people will naturally look for it).

+45
Dec 21 '11 at 16:26
source share

Comment by Chris Clark . You can cancel - so in development you do not want to have any restrictions (security or jndi, others)

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

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

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

and the comment will be visible.

+21
Feb 21 '13 at 15:36
source share

"matt b" has already sent a response, which is the most common way. That is how I would recommend doing this in 99% of cases.

However, sometimes your configuration file can be quite complex, and it makes no sense to duplicate the entire file for each environment when only one XML stanza is different. In these cases, you can abuse the filtering properties to achieve your goal.

Warning, because of this, a very permeable solution arises, and it will not be for the faint of heart:

In your pom.xml:

Warning StackOverflow Editors !!!!

The output of the html object is part of the solution. The solution will NOT WORK if you replace everything with larger and smaller characters. Please leave an 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} .... 

Since non-existent properties evaluate an empty string, your configurations that do not have this property set (or a property is an empty xml tag) will be evaluated with an empty string here.

This is ugly and the xml is hard to change in this form. However, if your web.xml is complex and you put the greater risk of 4-5 copies of web.xml coming out of sync, this might be the approach that will work for you.

+19
Jul 25 2018-10-25T00:
source share

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

It 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> 

Further information is available in the official documentation on filtering DeploymentDescriptors .

+10
Oct 09 '14 at 2:38
source share

Improvement overflow.site/questions/111466 / ...

Instead of specifying a custom property, use the default maven.war.webxml property in different profiles.

 <profiles> <profile> <id>profile1</id> <properties> <maven.war.webxml>path/to/custom/webXml</maven.war.webxml> </properties> </profile> </profiles> 

Further information can be found at the following link: https://maven.apache.org/plugins-archives/maven-war-plugin-2.4/war-mojo.html#webXml

+4
Nov 24 '14 at 13:30
source share
 is there a way to have two web.xml files and select the appropriate one depending on the profile? 

Besides the approach suggested by b, it is useful to think about it differently, mainly because in many cases you will have to bind specific application server configurations that are not covered by maven (afaik) plugins. They can very well distinguish between profiles.

In particular, you can use the parent project, which has all the common files between web projects of different profiles. Then child projects can have different web.xml files, and the rest id with profiles and maven-war-plugin . For example, I used this layout to achieve automatic assemblies (other than specifying a profile) for different target environments (development, uat, etc.).

 WebPc ├── common │ ├── css │ ├── images │ ├── js │ └── WEB-INF │ └──├── wsdl │── pom.xml │ ├── WebPc-DEV │ ├── pom.xml │ └── src │ └── main │ └── webapp │ └── WEB-INF │ ├── geronimo-web.xml │ ├── ibm-web-bnd.xml │ ├── ibm-web-ext.xml │ └── web.xml ├── WebPc-UAT │ ├── pom.xml │ └── src │ └── main │ └── webapp │ └── WEB-INF │ ├── geronimo-web.xml │ ├── ibm-web-bnd.xml │ ├── ibm-web-ext.xml │ └── web.xml 

Pom webpc has the following pom

 <groupId>my.grp</groupId> <artifactId>WebPc</artifactId> <packaging>pom</packaging> <profiles> <profile> <id>DEV</id> <activation> <activeByDefault>true</activeByDefault> </activation> <modules> <module>WebPc-DEV</module> </modules> </profile> <profile> <id>UAT</id> <modules> <module>WebPc-UAT</module> </modules> </profile> </profiles> <build> <pluginManagement> <plugins> <!-- copy common resources located on parent project common folder for packaging --> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-war-plugin</artifactId> <version>2.4</version> <configuration> <resourceEncoding>${project.build.sourceEncoding}</resourceEncoding> <webResources> <resource> <directory>../common</directory> <excludes> <exclude>WEB-INF/**</exclude> </excludes> </resource> <resource> <directory>../common/WEB-INF</directory> <includes> <include>wsdl/*.wsdl</include> <include>wsdl/*.xsd</include> </includes> <targetPath>WEB-INF</targetPath> </resource> </webResources> </configuration> </plugin> </plugins> </pluginManagement> </build> 

And this is the pom for WebPc-DEV

 <parent> <groupId>my.grp</groupId> <artifactId>WebPc</artifactId> <version>1.0.0-SNAPSHOT</version> </parent> <artifactId>WebPc-DEV</artifactId> <packaging>war</packaging> <build> <plugins> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-war-plugin</artifactId> </plugin> </plugins> </build> 
0
Sep 25 '13 at 14:31
source share



All Articles