We Keep Coding

How do I include a "resources" directory alongside (not in with) my built JAR/classes in Maven?

I'm using Maven in IntelliJ and I want to include a 'resources' directory in my build output alongside the JAR and/or in whatever directory IntelliJ uses as the cwd when running my project. I don't want these files in the JAR/Classpath, just alongside the final built project.
The idea is that then, my project can refer to files named things in src/ext-resources/foo.txt as resources/foo.txt.
I'm currently using the following instruction in pom.xml:
<build>
<plugins>
<plugin>
<artifactId>maven-resources-plugin</artifactId>
<version>2.6</version>
<executions>
<execution>
<id>copy-resources</id>
<phase>validate</phase>
<goals>
<goal>copy-resources</goal>
</goals>
<configuration>
<outputDirectory>${basedir}/target/resources</outputDirectory>
<resources>
<resource>
<directory>src/main/ext-resources</directory>
</resource>
</resources>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
However, this doesn't appear to actually make it accessible, and doesn't seem to be copying these files at all. At one point, my config resulted in the subdirectories of src/ext-resources being copied into target/classes for some reason, but they aren't being copied into target/resources no matter what.
How do I make maven copy this folder into my final output directory?

Maven Copy Folder Before War File Generation

I have two Git repositories. One repositary is java services (maven web project) and another repository consists of UI {HTML, JS, CSS}(non maven), At the time of java services repository build I want to include the latest UI (master) into the war file. I tried with maven-resources-plugin
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.2</version>
<configuration>
<source>1.7</source>
<target>1.8</target>
</configuration>
</plugin>
<plugin>
<artifactId>maven-resources-plugin</artifactId>
<version>2.7</version>
<executions>
<execution>
<id>copy-resources</id>
<!-- here the phase you need -->
<phase>install</phase>
<goals>
<goal>copy-resources</goal>
</goals>
<configuration>
<outputDirectory>${basedir}/target/</outputDirectory>
<resources>
<resource>
<directory>/home/srinivas/AAA/bb/</directory>
</resource>
</resources>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
mvn install
It copies the resources to target folder but it is not placing them in the war file

You are using the wrong phase in your execution as the package phase is actually the phase where your war is created, so you need to execute at an earlier phase e.g. prepare-package.
You should definitely read Introduction to the Build Lifecycle for clarification.
In addition you should not become accustomed to pulling in resources via maven-resources-plugin from the file system. This is generally frowned upon as bad practice since other developers will not be able to reproduce your build.
Using a repository manager to store your dependencies is the way to go here. Read Why do I need a Repository Manager? to get started.

at first glance, change :
<phase>install</phase>
to
<phase>prepare-package</phase>

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

maven-jar-plugin file filterring

I have a some perl file in my src/main/java/com/pac/report.pl which I want to package as part of my classes in the jar file.
Using maven maven-jar-plugin include directives, I have tried below and various other suggestions I pulled off the web, but doesn't copy the perl file as part of my classes in the jar file. Does anyone know what I am doing wrong.
<plugin>
<artifactId>maven-jar-plugin</artifactId>
<version>2.4</version>
<configuration>
<includes>
<include>**/*</include>
</includes>
</configuration>
</plugin>
EDIT
Also let me point out that I don't want to place the file in the resource directory due to legacy call and dependent reasons.

That is because the classes packaged into your jar aren't taken from src, but rather from target (specifically /target/classes), and the compiler completely ignores your non-java file.
Try placing your file in src/main/resources/com/pac/report.pl and it should be packaged into the jar (with the relative path of /com/pac/report.pl) since thats the default location where the resources plugin looks for additional files to add to /target before the jar plugin runs.
EDIT - or, if you dont want to / cant do this the way maven expects, you could manually bind an execution of the resources plugin to the lifecycle to pick up your file and copy it over to target. something like this:
<build>
<plugins>
<plugin>
<artifactId>maven-resources-plugin</artifactId>
<version>2.6</version>
<executions>
<execution>
<id>copy-resources</id>
<phase>compile</phase> <!-- or later -->
<goals>
<goal>copy-resources</goal>
</goals>
<configuration>
<outputDirectory>${basedir}/target/classes</outputDirectory>
<resources>
<resource>
<!-- path to your *.pl file here -->
</resource>
</resources>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
...
</build>

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 !