Message-ID: <2096620231.299390.1368978928001.JavaMail.email@example.com> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_299389_19929588.1368978928000" ------=_Part_299389_19929588.1368978928000 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
If you have an application that you are building with maven2 that you wi= sh to merge two WAR files together, then you may wish to use the 'uberwar' = mojo present in the cargo maven2 plugin.
An "uberwar" is a war file constructed from 2 or more War file= s, where the deployment descriptors in files such as web.xml have been comb= ined.
Create a maven2 project whose output artifact is going to be the uberwar= . Don't forget to add as dependencies the War files you're going to make th= e uberwar from.
Your packaging type should be uberwar:
Next, you need to add the cargo maven plugin to your
t; section, and set it up with the path to a merging descriptor:
src/assemble/merge.xml is the descriptor of how yo=
u want the merge to work (see next section for detailed explanations).
Note that plugin configuration also supports the
The merge descriptor file specifies the content of the resulting uberwar= file.
Here is a sample of the minimal merge descriptor:
The following merge descriptor elements are supported:
In order to know which war files to merge, and in which order (this is s=
ignificant - for example, when you choose overwrite strategy), specify them=
<wars> element. Each
b-element should be of form
to be properly resolved.
If you have files that need to be merged together by some kind of proces=
sor, then specify it here. The classname can be
dule.webapp.DocumentMerger, which is a simple class that will merge =
by copying all xml nodes from the descriptor files. Alternatively, you can =
provide any class that is available on the classpath, provided it implement=
t;merges> element is optional. You can have as many
ge> sub-elements as you need.
web.xml= code> file
The uberwar plugin will merge your
The ability to merge
web.xml is probably the most important=
piece of uberwar functionality. This is achieved by providing a special
For each tag in the
web.xml, the descriptor is defining how=
you want the merge to happen (the 'strategy'). There are 4 out-of-the-box =
strategies, and you can provide your own by passing the name of a class tha=
code>. These strategies define what should happen if an entry is just in on=
e file, or what to do if there is a conflict. When merging, each successive=
file is merged in sequence - so if there are 3 merges to do, the first two=
files will be merged together, then the result will be merged with the las=
t file. In each merge operation, the first of the two files is the 'left ha=
nd side', and the second of the two files is the 'right hand side' (think o=
f source code merge utilities).
The defaults strategies are:
Preserve means "if there is a conflict, then preserve the original&= quot;.
Overwrite means "if there is a conflict, then use the values in the= right-hand side". This is the default strategy if nothing else is specified.
NodeMerge means "I want to do some merge resolution". The conf=
iguration of this strategy is the XML that the conflicting node will be rep=
laced with. Anything starting with
$left: will be translated a=
s an XPath expression, executed against the left-hand descriptor. The effec=
$right: is the same for the right-hand side.
ChooseByName means "most of the time, I want to use one strategy, b=
ut for a particular named item, I want to do something else". The conf=
iguration of this strategy must contain single
sub-element (specifying default merge strategy) and multiple
ice> sub-elements (specifying merge strategy for specific tag ins=
In the example above:
<display-name>element from the last war file= being merged will be used
<welcome-file-list>definitions will be merge= d (assuming that we are merging two war files, each one specifies at most s= ingle welcome file)
.uberwarextension. It does not do this if the project is built on its own.
xerc= es:xercesImplto the plugin's dependencies. That error should not be= happening as of Java 6.