Enterprise Java Development@TOPIC@
In the previous sections we used several commands as a part of the build. We will now take a moment to describe a few of them so it is more evident they exist and how they can be useful.
Maven builds modules in phases and in a specific phase ordering. We won't discuss all of them here, but we will hit the ones of importance to server-side development. Try each of the following commands from the root/parent directory and also watch the output in the server.log.
$ tail -n 999 -f standalone/log/server.log
$mvn (phase)
mvn clean
Delete previously built artifacts below the target tree(s).
mvn process-test-classes
mvn test
Run unit tests (i.e., classes matching surefire file name pattern)
mvn package
Build Java, EJB, WAR, and EAR archives
mvn pre-integration-test
Deploy deployable archives for the module. Note this is a per-module basis. If you have separate IT modules, each module is responsible for deploying its required artifacts. This is a very useful target when running the IT test within the IDE and outside of the Maven framework once deployed to the server.
mvn integration-test
Run integration tests (IT tests) (i.e., classes matching failsafe file name pattern)
mvn post-integration-test
Undeploy deployed archives for the module. Note this is a per-module basis. If you have separate IT modules, each module is responsible for undeploying its required artifacts. If these artifacts are needed by a downstream module build they will need to be re-deployed by that downstream module.
mvn verify
Evaluate the IT test results and wait to fail until this point so that the deployed artifacts can be undeployed.
mvn install
Install the built artifacts into the local repository to make them available to downstream modules when building outside the context of a common parent. i.e., If you build from the parent of an EJB and EAR, the EAR will be given knowledge of the EJB through the parent. If you build only the EAR, the latest installed version of the EJB in the local repository will be used.
It is common, when building a multi-module application that the first set of modules build fine but an error is encountered when building one of the later modules.
Re-build just the WAR and RMI Test modules by naming the module to start with. Based on the order specified in the parent pom, we will start with the RMI Test module.
<modules>
<module>basicejb-ejb</module>
<module>basicejb-ear</module>
<module>basicejb-test</module>
<module>basicejb-war</module>
</modules>$ mvn clean install -rf :basicejb-test ... [INFO] Reactor Summary: [INFO] [INFO] Basic EJB Exercise::Remote Test .................... SUCCESS [ 8.018 s] [INFO] Basic EJB Exercise::WAR ............................ SUCCESS [ 3.030 s] ... [INFO] BUILD SUCCESS
There are times when you are looking to build one of the child modules or a branch of the child module tree but you do not want the build to continue from that point. You likely know that you can execute a build in that module's directory or you can stay in the same directory and point to the module you would like built. This technique is useful when you configure a build server to build specific bootstrap modules (in your tree checked out from CM) prior to moving on to build the remaining modules.
The parameter to -f is a file reference and not a module name. You can use this to refer to a parent (e.g., mvn clean -f ../pom.xml), siblings, as well as children. Lets say you are in src/test/resources actively editing jndi.properties. You can issue a building command that looks like
$ mvn clean process-test-resources -f ../../../pom.xml
Re-build just the RMI Test module from the root directory by specifying the module to the build.
$ mvn clean install -f basicejb-test/pom.xml ... [INFO] BUILD SUCCESS
There are times when you would like to undeploy a deployed archive without re-deploying again first. This is common as part of the "mvn clean" lifecycle and allows you to undeploy everything you have before deploying the next version on a multi-deployment setup.
<profiles>
<!-- this profiles allow the EAR to be undeployed before it is deleted
during the clean target. This behavior requires the EAR to be
present, so it cannot be part of the default behavior. It is
only activated when -Pundeploy is present so that
normal cleans do not fail. -->
<profile>
<id>undeploy</id>
<build>
<plugins>
<plugin>
<groupId>org.codehaus.cargo</groupId>
<artifactId>cargo-maven2-plugin</artifactId>
<executions>
<execution>
<id>undeploy-ear</id>
<phase>pre-clean</phase>
<goals>
<goal>undeploy</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
</profile>
</profiles>
Deploy the EAR and WAR artifacts to the server and note that they are deployed using the console or server.log.
$ mvn clean pre-integration-test
# server.log 2014-10-11 17:24:02,553 INFO [org.jboss.as.server] (management-handler-thread - 1) JBAS018559: Deployed "basicejb-ear-1.0-SNAPSHOT.ear" (runtime-name : "basicejb-ear-1.0-SNAPSHOT.ear") ... 2014-10-11 17:24:04,157 INFO [org.jboss.as.server] (management-handler-thread - 1) JBAS018559: Deployed "basicejb-war-1.0-SNAPSHOT.war" (runtime-name : "basicejb-war-1.0-SNAPSHOT.war")
This is the point in which we can run our IT tests within the IDE once we resolve a few remaining dependencies on the failsafe plugins (later...)
Undeploy the EAR and WAR artifacts from the server and note they are undeployed using the output of the console or server.log.
$ mvn clean -Pundeploy
2014-10-11 17:24:15,019 INFO [org.jboss.as.server] (management-handler-thread - 1) JBAS018558: Undeployed "basicejb-ear-1.0-SNAPSHOT.ear" (runtime-name: "basicejb-ear-1.0-SNAPSHOT.ear") ... 2014-10-11 17:24:15,662 INFO [org.jboss.as.server] (management-handler-thread - 1) JBAS018558: Undeployed "basicejb-war-1.0-SNAPSHOT.war" (runtime-name: "basicejb-war-1.0-SNAPSHOT.war")
To execute a single IT test case use the following
$ mvn verify -f basicejb-test -Dit.test=org.myorg.basicejb.earejb.ReservationIT
To execute a single IT test case method use the following
$ mvn verify -f basicejb-test -Dit.test=org.myorg.basicejb.earejb.ReservationIT#testPing
Maven and surefire have made it very tough to skip unit tests and only run a specific IT test. However, you can always add a temporary set of includes/excludes to the surefire configuration in order to achieve the sometimes-desired result of turning off any preceding unit tests. Note that this is not an issue when IT tests are hosted in a separate module.
Leverage build lifecycle phases to build what is needed
Keeps from executing the entire build lifecycle
Required in some cases (deployment) to achieve desired results (stay deployed)
Re-start the build at a specific module
Saves time from building unchanged modules
User must know that skipped modules are not needed
Undeploy module artifact
Enables cleanup prior to a re-deploy
Good for when having multiple application deployments with dependencies between them