It is recommended to use the maven-war-plugin approach described in Section 4.1.3, “Using the maven-war-plugin”, as it is the most flexible one. The disadvantage of duplicating the properties and configuration files is outweighed by several other advantages:
The maven-war-plugin produces an archive as the resulting artifact, there is no need to configure additional steps. Because the resulting
WARfile is automatically the main artifact of the module, it can be deployed to a repository using Mavensdeploygoal. With the coremedia-application-maven-plugin, you would have to use an extra plugin to attach the artifact to the module before you can deploy it with Maven.The fact that each web application is mapped to one Maven module allows individual versioning of the deployable artifacts. The idea is not to use the maven-release-plugin at all, but to keep stable snapshot versions for all modules below the
modulesfolder and use fix versioned POM files for all the new WebSphere deployment modules. In combination with a VCS that has a unique ID for each state of its repository; this ID is the only important reference to the source state of your deployed application. To identify the state of libraries in production, make sure that these IDs are written to the manifestMETA-INF/MANIFEST.MFof any library you create in the workspace.Overwriting property and configuration files instead of filtering or modifying them has the advantage that file attributes like creation time or last modification date remain the same when the original data has not changed. Recreating or redeploying an unchanged archive can be detected and skipped.
 |  |  |
 |