Conditional exclusion of file from compilation in maven project - java

What the easiest/right way to conditionally exclude a java file from compilation in a maven project?
I would like to be able to set a 'boolean' properties in the pom.xml:
<properties>
<IncludeMayBe>true</IncludeMayBe>
</properties>
...
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>2.3.2</version>
<configuration>
<excludes>
????
</excludes>
</configuration>
</plugin>
Is there a way to fiddle something with the compiler plugin? Or should I go for profiles? I feel like creating a profile is overkill, but may be this is the only solution...
EDIT:
We have established that profiles are the solution. For conditional activation from within the pom.xml, one can use the following:
<profiles>
<profile>
<activation>
<property>
<IncludeMayBe>true</IncludeMayBe>
</property>
</activation>
...
</profile>
</profiles>

I suggest you use the Build helper maven plugin.
Using this, you can have several source directories.
Then you can control what source directories are included using profiles.
Assuming you have your monitoring classes under src/monitoring/java you could add the following to the element in your pom.xml
<profiles>
<profile>
<id>monitoring</id>
<build>
<plugins>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>build-helper-maven-plugin</artifactId>
<version>1.5</version>
<executions>
<execution>
<id>add-sources</id>
<phase>generate-sources</phase>
<goals>
<goal>add-source</goal>
</goals>
<configuration>
<sources>
<source>${basedir}/src/monitoring/java</source>
</sources>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
</profile>
</profiles>

You cannot do this using the compiler plugin (see below).
But even if you could, it doesn't feel right. It would mean that the files in a artifact JAR file would depend on command line switches and/or environmental settings, and that makes it harder for other folks to reproduce builds.
My gut feeling is that you'd be better of modularizing your maven project and using profiles to determine what modules get built.
I had a look at the source code of the compiler plugin mojo, and it looks like there's no way to configure source include / exclude filters. At some point, someone has implemented filters, but the relevant Map objects are private and there is no way to populate them, and hence no way to use this functionality.
The code is here: http://svn.apache.org/viewvc/maven/plugins/tags/maven-compiler-plugin-2.3.2/src/main/java/org/apache/maven/plugin/
I guess you could hack your own version of the plugin ... but it seems like a bad idea.

Related

Is it possible to compile grunt project from maven?

I'm trying to execute grunt tasks from within maven without needing to install Node.js or anything. This is because I wan't my artifact to be packaged by Jenkins and I can't install Node.js on that machine.
I know that it's easy with npm and a few commands to get it working, but I also think that it should be easy to integrate with maven, the problem is that I don't know where to start since I'm new to npm.
Yes, using the frontend-maven-plugin, you can compile Grunt projects via Maven (found via the NodeJS mailing list).
As the documentation points out, the plugin has the following features:
Let you keep your frontend and backend builds as separate as possible, by reducing the amount of interaction between them to the bare minimum; using only 1 plugin.
Let you use Node.js and its libraries in your build process without installing Node/NPM globally for your build system
Let you ensure that the version of Node and NPM being run is the same in every build environment
I've walked through the code and it's fairly simple. Thank goodness someone finally put this together; it's an elegant solution. The repository includes an example that uses a regular Gruntfile.js to invoke jshint analysis.
UPDATE 2014-09-19: This is no longer the most accurate answer - please take a look at some of the other answers below. It was accurate at the time when I answered the question, but there seems to have been a good deal of progress in this area since then.
I'm afraid you're out of luck. Grunt is built using node and needs to be installed using npm. You might be able to copy an existing installation of Grunt from another machine if you don't want to use npm, but will still use the grunt executable and all of its dependencies on your build server.
In addition to that, many of the Grunt tasks are implemented as Node.js modules, and you will have to install them as well. Again, you might be able to copy them from another server, where you've done the Node.js/Grunt installation, but at one point, you have to do it.
For running Grunt from Maven, your best bet is to use the Maven exec plugin and then execute the grunt executable from there.
As an alternative, there are several Maven plugins that allow you to do things similar to Grunt in a Java-based fashion. They require additional configuration not compatible with Grunt, so YMMV. One that I've used in the past is http://code.google.com/p/wro4j/, which comes with a Maven plugin as well: http://code.google.com/p/wro4j/wiki/MavenPlugin
Any particular reason why you can't install Node.js on your build server?
You can use grunt-maven-plugin. It allows you to easily integrate Grunt tasks into Maven build process. No dirty hacks.
This is what I use in my current project and it works just perfect.
Finally I ended up with this (which is close enough but doesn't solve the problem):
<plugin>
<groupId>org.mule.tools.javascript</groupId>
<artifactId>npm-maven-plugin</artifactId>
<version>1.0</version>
<executions>
<execution>
<phase>generate-resources</phase>
<goals>
<goal>fetch-modules</goal>
</goals>
<configuration>
<packages>
<package>grunt-cli:0.1.6</package>
</packages>
</configuration>
</execution>
</executions>
</plugin>
that installs locally the grunt-cli, but if I don't have installed node.js it's worthless. Although I try to install node.js locally there's the need to have installed python, g++ and make. So I'll go with the KISS solution: install grunt in the build server.
References:
https://github.com/mulesoft/npm-maven-plugin
https://github.com/joyent/node/wiki/Installing-Node.js-via-package-manager
https://github.com/mcheely/requirejs-maven-plugin
You might want to checkout http://jhipster.github.io/ : it's a Yeoman generator, that generates an application which has Maven, Grunt and Bower all working together.
It's a bit like your third option, but everything is configured for you, which isn't that easy. It's also generating the basic AngularJS and Java REST services for you
This is a full copy/paste solution which work in 2017 using frontend-maven-plugin for front build, and maven-war-plugin to build the war.
What it does ? install npm, bower grunt,and everything you need, then run npm install, bower install and finally grunt build.
You can remove/add replace the steps you want, for me it's a full 30 sec install/build library and project.
<dependencies>
...
</dependencies>
<dependencyManagement>
<dependencies>
<!-- https://mvnrepository.com/artifact/com.github.eirslett/frontend-maven-plugin -->
<dependency>
<groupId>com.github.eirslett</groupId>
<artifactId>frontend-maven-plugin</artifactId>
</dependency>
</dependencies>
</dependencyManagement>
<build>
<pluginManagement>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-war-plugin</artifactId>
<version>2.4</version>
<configuration>
<warSourceDirectory>src/main/webapp/YourFrontJsFolder/dist</warSourceDirectory>
<warName>YouWarName</warName>
<failOnMissingWebXml>false</failOnMissingWebXml>
<warSourceExcludes>node_modules/**</warSourceExcludes>
<includeScope>system</includeScope>
<webResources>
<resource>
<directory>WebContent/WEB-INF</directory>
<targetPath>WEB-INF</targetPath>
<includes>
<include>**/*.jar</include>
<include>**/*.jsp</include>
</includes>
</resource>
</webResources>
</configuration>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.3</version>
<configuration>
<source>1.7</source>
<target>1.7</target>
<encoding>Cp1252</encoding>
</configuration>
</plugin>
</plugins>
</pluginManagement>
<finalName>YourAppName</finalName>
</build>
<profiles>
<profile>
<id>release</id>
<build>
<plugins>
<plugin>
<groupId>com.github.eirslett</groupId>
<artifactId>frontend-maven-plugin</artifactId>
<executions>
<execution>
<!-- optional: you don't really need execution ids, but it looks
nice in your build log. -->
<id>install node and npm</id>
<goals>
<goal>install-node-and-npm</goal>
</goals>
<!-- optional: default phase is "generate-resources" -->
<phase>generate-resources</phase>
<configuration>
<nodeVersion>v7.6.0</nodeVersion>
</configuration>
</execution>
<execution>
<id>npm install</id>
<goals>
<goal>npm</goal>
</goals>
<!-- optional: default phase is "generate-resources" -->
<phase>generate-resources</phase>
<configuration>
<arguments>install</arguments>
</configuration>
</execution>
<execution>
<id>bower install</id>
<goals>
<goal>bower</goal>
</goals>
<configuration>
<!-- optional: The default argument is actually "install", so unless
you need to run some other bower command, you can remove this whole <configuration>
section. -->
<arguments>install</arguments>
</configuration>
</execution>
<execution>
<id>grunt build</id>
<goals>
<goal>grunt</goal>
</goals>
<!-- optional: the default phase is "generate-resources" -->
<phase>generate-resources</phase>
<configuration>
<!-- optional: if not specified, it will run Grunt's default task
(and you can remove this whole <configuration> section.) -->
<arguments>build</arguments>
</configuration>
</execution>
</executions>
<configuration>
<installDirectory>target</installDirectory>
<workingDirectory>src/main/webapp/YourFrontJsFolder</workingDirectory>
</configuration>
</plugin>
</plugins>
</build>
</profile>
<profile>
<id>debug</id>
<activation>
<activeByDefault>true</activeByDefault>
</activation>
</profile>
<profile>
<id>IDE</id>
<activation>
<property>
<name>m2e.version</name>
</property>
</activation>
<build>
<!-- Put the IDE's build output in a folder other than target, so that
IDE builds don't interact with Maven builds -->
<directory>target-ide</directory>
</build>
</profile>
</profiles>
Then you can Run as -> Maven build ..., with goal clean install and profile release
The first problem is that Maven is Java, but Grunt.js runs on the Node.js runtime. The easiest integration I ever achieved between the two involved the maven-exec-plugin. The maven-exec-plugin is capable of executing .sh/.bat/.cmd scripts, whichever are native to the OS you are using. So during a Maven build I would have the maven-exec-plugin execute a script named optimize-js.sh, for example, which would simply do something like “grunt release –force”, or whatever. The scripts can be made to do whatever. The important thing is to configure the maven-exec-plugin to execute them in the correct working directory. Of course, “grunt” and “node” need to be executable from the command-line.
If the problem is installing NodeJS on the Jenkins machine then you can use the NodeJS Jenkins plugin.
https://wiki.jenkins-ci.org/display/JENKINS/NodeJS+Plugin
We're not using it with Maven (yet) but we've got grunt running.
Can be done with exec-maven-plugin.
Define a script and dependency to grunt-cli in your package.json:
...
"scripts": {
"build": "./node_modules/.bin/grunt install"
},
"devDependencies": {
"grunt-cli": "^1.2.0",
...
In your pom, add the commands to run:
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>exec-maven-plugin</artifactId>
<version>X.Y.Z</version>
<executions>
<execution>
<id>exec-npm-install</id>
<phase>generate-sources</phase>
<configuration>
<workingDirectory>${project.basedir}</workingDirectory>
<executable>npm</executable>
<arguments>
<argument>install</argument>
</arguments>
</configuration>
<goals>
<goal>exec</goal>
</goals>
</execution>
<execution>
<id>exec-grunt-install</id>
<phase>generate-sources</phase>
<configuration>
<workingDirectory>${project.basedir}</workingDirectory>
<executable>npm</executable>
<arguments>
<argument>run</argument>
<argument>build</argument>
</arguments>
</configuration>
<goals>
<goal>exec</goal>
</goals>
</execution>
</executions>
</plugin>
It will now run on mvn package

How to exclude java classes from being compiled in maven with annotation

I already have a working solution where I can specify with maven which classes to not compile when using a particular maven profile.
But I would like to use a general solution and use an annotation instead
The current solution that I have is like
<plugin>
<!-- Exclude some web services used only for internal testing -->
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<configuration>
<optimize>true</optimize>
<excludes>
<exclude>**/something/*ClassPattern.java</exclude>
</excludes>
<testExcludes>
<exclude>**/something/*ClassPatternTest.java</exclude>
</testExcludes>
</configuration>
</plugin>
But Some thing like
#NotCompiledForProduction
would be rather nice on top of a class.
It seems to me that this might be hard (or impossible to do) without changing maven's behaviour. That is not the scope here. And this kind of annotation
You cannot (I assume) use an annotation to determine what source code gets presented to the java compiler, because you need to compile the source code in the first place to process the annotation.
It seems like you need to create different modules in your maven project: one that generates a jar file with the production code, and one module that generates a jar file with testing implementation with a dependency on the production artifact.
If the code really does need to be in the same maven module, then the code should always be compiled. You can however use maven-jar-plugin to create multiple artifacts at the package phase: the default artifactId.jar, and an artifactId-test-lib.jar artifact. You can do this by specifying multiple executions for the plugin, and using <includes> and <excludes> to split the jar files as required.
you can try this...
<build> <plugins>
<!-- Run annotation processors on src/main/java sources -->
<plugin>
<groupId>org.bsc.maven</groupId>
<artifactId>maven-processor-plugin</artifactId>
<executions>
<execution>
<id>process</id>
<goals>
<goal>process</goal>
</goals>
<phase>generate-sources</phase>
</execution>
</executions>
</plugin>
<!-- Disable annotation processors during normal compilation -->
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<configuration>
<compilerArgument>-proc:none</compilerArgument>
</configuration>
</plugin>
</plugins> </build>

executing a script from maven inside a multi module project

I have this multi-module project.
In the beginning of each build I would like to run some bat file.
So i did the following:
<profile>
<id>deploy-db</id>
<build>
<plugins>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>exec-maven-plugin</artifactId>
<version>1.1.1</version>
</plugin>
</plugins>
<pluginManagement>
<plugins>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>exec-maven-plugin</artifactId>
<version>1.1.1</version>
<executions>
<execution>
<phase>validate</phase>
<goals>
<goal>exec</goal>
</goals>
<inherited>false</inherited>
</execution>
</executions>
<configuration>
<executable>../database/schemas/import_databases.bat</executable>
</configuration>
</plugin>
</plugins>
</pluginManagement>
</build>
</profile>
when i run the mvn verify -Pdeploy-db from the root I get this script executed over and over again in each of my modules.
I want it to be executed only once, in the root module.
What is there that I am missing ?
Thanks
I might be mistaken but when you add a plugin to the <pluginManagement> section each and every sub-module inherits it and "runs" it.
I think that you should move you exec-maven-plugin and its <execution> to the normal <plugins> section.
So the issue you're having is that you're trying to do something in the parent POM. That's not how parent poms are designed in maven (i.e. not "the maven way"). You should only perform actions in "leaf node" poms, the parents are just for aggregation and putting shared behavior that should be reused in each child.
So the simple answer at how to call your script is to analyze the dependencies between your children to determine which needs to happen first (and impose dependency if necessary to enforce this), then add the plugin to that child. If it doesn't fit well in that child for some reason, you can make another child that just performs this action.
On a side note, never reference relative file paths in maven. You're using "../database/schemas/import_databases.bat". If import_databases.bat isn't inside the project directory then assuming it's in the parent directory is asking for a mess. You should instead use something like "${basedir}/src/main/scripts/import_databases.bat"

Maven project dependency against JDK version

I have projects that need to be build with a specific version of the JDK.
The problem isn't in the source and target parameters but in the jars of the runtime used during compilation.
In some cases I get a compilation error if I try to compile with the wrong JDK, but sometimes the build is successful and I get runtime errors when using the jars.
For example in eclipse I have the ability to establish the execution enviroment for the project in the .classpath file.
Is there a way to handle such situation in maven?
What I would like to have is the ability to handle JRE dependency like other dependencies of the project in the POM file.
UPDATE:
The accepted solution was the best one when I asked this question, so I won't change it. Meanwhile a new solution to this kind of problems has been introduced: Maven Toolchain. Follow the link for further details.
I've found this article:
http://maven.apache.org/plugins/maven-compiler-plugin/examples/compile-using-different-jdk.html
<project>
[...]
<build>
[...]
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>2.1</version>
<configuration>
<verbose>true</verbose>
<fork>true</fork>
<executable>${JAVA_1_4_HOME}/bin/javac</executable>
<compilerVersion>1.3</compilerVersion>
</configuration>
</plugin>
</plugins>
[...]
</build>
[...]
</project>
I have projects that need to be build with a specific version of the JDK.
You can use the Maven Enforcer plugin to enforce the use of a particular version of the JDK:
<project>
[...]
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-enforcer-plugin</artifactId>
<executions>
<execution>
<id>enforce-versions</id>
<goals>
<goal>enforce</goal>
</goals>
<configuration>
<rules>
<requireJavaVersion>
<version>1.5</version>
</requireJavaVersion>
</rules>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
[...]
</project>
But I'm not sure I really understood the question. If this is not what you want, maybe you could declare your JDK specific dependencies in profiles and use an activation trigger based on the JDK version. For example:
<profiles>
<profile>
<activation>
<jdk>1.5</jdk>
</activation>
...
</profile>
</profiles>
This configuration will trigger the profile when the JDK's version starts with "1.5".
I believe that this can be solved with following plugin in your pom:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>2.1</version>
<configuration>
<source>1.6</source>
<target>1.6</target>
</configuration>
</plugin>
Here you target version 1.6 , or write your own version

How do I get Maven 2 to build 2 separate WAR files

When doing a mvn install I want to end up with 2 WAR files in my target directory. One will contain the production web.xml and the other will contain the test/uat web.xml.
I've tried this:
<build>
<finalName>cas-server</finalName>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-war-plugin</artifactId>
<version>2.1-beta-1</version>
<configuration>
<webXml>src/main/config/prod/web.xml</webXml>
<warName>cas-prod</warName>
</configuration>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-war-plugin</artifactId>
<version>2.1-beta-1</version>
<configuration>
<webXml>src/main/config/test/web.xml</webXml>
<warName>cas-test</warName>
</configuration>
</plugin>
</plugins>
</build>
But I only end up with the test WAR.
I don't think you can do this in one step (actually, I'm surprised that Maven doesn't complain about your setup and wonder which one is applied) and I'd suggest to use profiles and maybe filtering to manage this use case.
If your web.xml are really different, you could just put your maven-war-plugin configuration in two profiles. Or, better, you could merge them into something like this:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-war-plugin</artifactId>
<version>2.1-beta-1</version>
<configuration>
<webXml>src/main/config/${env}/web.xml</webXml>
<warName>cas-test</warName>
</configuration>
</plugin>
And set the env property in two profiles to pick up the right web.xml at build time.
<profiles>
<profile>
<id>uat</id>
<properties>
<env>test</env>
</properties>
</profile>
<profile>
<id>prod</id>
<properties>
<env>prod</env>
</properties>
</profile>
</profiles>
If your web.xml are similar (i.e. if only values differ in them), you could define properties and their values in two profiles and use filtering to apply them. Something like this:
<profiles>
<profile>
<id>env-uat</id>
<activation>
<property>
<name>env</name>
<value>uat</value>
</property>
</activation>
<properties>
<key1>uat_value_key_1</key1>
<keyN>uat_value_key_n</keyN>
</properties>
</profile>
<profile>
<id>env-prod</id>
<activation>
<property>
<name>env</name>
<value>prod</value>
</property>
</activation>
<properties>
<key1>prod_value_key_1</key1>
<keyN>prod_value_key_n</keyN>
</properties>
</profile>
</profiles>
Then activate one profile or the other by passing the env property on the command line, e.g.:
mvn -Denv=uat package
Another option would be to put the values into specific filters and pick up the right one at build time (like in this post).
There are really many options but as I said, I don't think you can do this without runngin the build twice.
More resources on profiles/filtering:
Maven Book: Chapter 11. Build Profiles
Maven Book: Chapter 15.3. Resource Filtering
Introduction to Build Profiles
Use an alternative Maven Profile during test phase
maven profile filtering search on Google
You can tell the Maven Assembly plugin to simply generate two assemblies. You just write an assembly descriptor file for each output you wish to create and list them in the plugin config.
For example I'm using it to generate a WAR file and a TGZ file, but there's no reason you can't do two WARs in the same way. mvn package will then generate both files.
<plugin>
<artifactId>maven-assembly-plugin</artifactId>
<version>2.3</version>
<configuration>
<descriptors>
<descriptor>src/main/assembly/assembly-war.xml</descriptor>
<descriptor>src/main/assembly/assembly-dist.xml</descriptor>
</descriptors>
</configuration>
<executions>
<execution>
<id>dist-assembly</id>
<phase>package</phase>
<goals>
<goal>single</goal>
</goals>
</execution>
</executions>
</plugin>
I'd generally suggest to use profiles and run two dedicated builds. However, it should be possible to create any number of artifacts using the maven-assembly-plugin.
Old Question, but I want to answer for completeness.
You can do this in one build step very simply with the war plugin with two executions. See the sample code below:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-war-plugin</artifactId>
<executions>
<execution>
<id>build-context-one</id>
<phase>install</phase>
<goals>
<goal>war</goal>
</goals>
<configuration>
<classifier>context-one</classifier>
<webResources>
<resource>
<filtering>true</filtering>
<directory>src/main/webapp</directory>
<includes>
<include>**</include>
</includes>
</resource>
<resource>
<directory>your-context-one-directory</directory>
</resource>
</webResources>
</configuration>
</execution>
<execution>
<id>build-context-two</id>
<phase>install</phase>
<goals>
<goal>war</goal>
</goals>
<configuration>
<classifier>classifier-two</classifier>
<webResources>
<resource>
<filtering>true</filtering>
<directory>src/main/webapp</directory>
<includes>
<include>**</include>
</includes>
</resource>
<resource>
<directory>your-context-two-directory</directory>
</resource>
</webResources>
</configuration>
</execution>
</executions>
I think this can only be achieved by writing a custom Maven plugin or interfering with the build lifecycle and running the war assembling process twice (this is just a faint idea).
Maybe you could create two profiles and run the goal twice with different profiles (mvn -P prof1 package, mvn -P prof2 package), but be careful with the generated artifact names, they shouldn't be overwritten. Or you might be able to create a custom plugin that uses other plugins and assembles the two war files.
While I don't use Maven but Ivy instead, here's how you should generally do this:
Have your own application published in to a private repository/similar as JAR with its dependencies/other static stuff and then individual project settings for building the application's deployment specific WARs with context specific configurations. Now by building any of the individual deployment projects you get the latest version of your actual application with its build specific configurations.
I would assume that since this is trivial in Ivy, Maven should be able to do it just as easily.
Sort-of-ugly hack (it breaks Maven's idea of declaring intentions instead of actions), but worked for me: I had to generate two wars which shared the same back-end code base, but varied on the MVC controller packages.
After banging my head with several plugins, I thought "hey, I'd do it easily in ant", which lead me to use <maven-antrun-plugin> to generate the wars during the "package" phase (on which we arlready have all the files). Sort of like this:
<plugin>
<artifactId>maven-antrun-plugin</artifactId>
<version>1.3</version>
<executions>
<execution>
<phase>package</phase>
<goals>
<goal>run</goal>
</goals>
<configuration>
<tasks>
<delete file="target/war-1.war" />
<delete file="target/war-2.war" />
<war destfile="target/war-1.war">
<fileset dir="target/original">
<exclude name="**/WEB-INF/classes/package_of_war2/**" />
</fileset>
</war>
<war destfile="target/war-2.war">
<fileset dir="target/original">
<exclude name="**/WEB-INF/classes/package_of_war1/**" />
</fileset>
</war>
<delete file="target/original.war" /
</tasks>
</configuration>
</execution>
</executions>
</plugin>
(to be fair, I did not delete the original file, but you should be able to do so.)
In your case, you could package one war without the alternate web.xml, rename/move it over the original web.xml, then package the second war.
More simple:
Just create a multi modules project.
Each module would have the WAR packaging :)
Build from parent pom and voila !

Categories