Message-ID: <705556379.3649.1369396681926.JavaMail.email@example.com> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_3648_437026217.1369396681925" ------=_Part_3648_437026217.1369396681925 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
Cargo supports deploying=
to an already running container. This feature is called [Hot Deployment). =
You call it by using the (
cargo:deploy) goal =
Note that you can also do static deployment by simply def=
ining the deployables to deploy in the
lement as shown in the Starting and stopping a container tutorial. In that case the d=
eployables will be deployed before the container starts.
|Not all containers have a Deployer implemented|
We= haven't finished implementing Deployers for all containers yet. Please check if your favorite container has= it implemented. If not you'll need to deploy your deployables by defining = them in a standalone local configuration as shown in the Starting and stopping a containe= r use case.
ut WAR contexts|
Many containers have their specific files for r= edefining context roots (Tomcat has context.xml, JBoss has jboss-web.xml, e= tc.). If your WAR has such a file, the server will most probably use the co= ntext root defined in that file instead of the one you specify using the CA= RGO deployer.
A local deployer is a deployer that deploys deployable=
s on a Local Container (i.e.=
a container installed on the same machine where the deployer is executing)=
. Thus you'll need to use a local container id in
. You can check that by reviewing the supported container list and selecting the container you wish t=
Example of doing a local deploy to an existing configu= ration:
As for the
cargo:start goal if your project is =
a J2EE project then the generated artifact will be automatically added to t=
he list of deployables to deploy.
A remote deployer is a deployer that deploys deployables=
on a Remote Container (i.e=
. a container that is running and that has been started externally from Car=
go). Thus you'll need to use an id for a remote container in
ainerId> and a R=
Example of doing a remote deploy us= ing a runtime configuration:
[...] <configuration> <!-- Container configuration --> <container> <containerId>tomcat6x</containerId> <type>remote</type> </container> <!-- Configuration to use with the container --> <configuration> <type>runtime</type> <properties> <cargo.remote.username>username</cargo.remote.username> <cargo.remote.password>password</cargo.remote.password> </properties> </configuration> <!-- Deployer configuration --> <deployer> <type>remote</type> </deployer> <!-- Deployables configuration --> =C2=A0<deployables> <deployable> <groupId>war group id</groupId> <artifactId>war artifact id</artifactId> <type>war</type> <properties> <context>optional root context</context> </properties> <pingURL>optional url to ping to know if deployable is done or = not</pingURL> <pingTimeout>optional timeout to ping (default 20000 millisecon= ds)</pingTimeout> </deployable> [...] </deployables> </configuration> [...]=09=09
As you can see the information to connect and do the deploym=
ent to the remote container is specified in the runtime configuration (
properties to define are deployer-dependent.
Here's an another examp= le, this time deploying the current project's artifact to a running JBoss 4= .2.x container using a default 8080 port and default authorizations:
[...] <configuration> <container> <containerId>jboss42x</containerId> <type>remote</type> </container> </configuration> [...]=09=09
mvn cargo:deploy. Notice that we have=
n't specified a
<deployer> element nor a
guration> one: this is because the plugin is smart enough to crea=
te default instances for you.
If the deployment, undeployment or redeployment is don= e without any watchdog, CARGO will rely on the error codes return by the co= ntainer's deployer to detect failures.
This is sometimes not desired:=
for example, if one calls=C2=A0
cargo:undeploy but the target =
deployable (be it a web application, EAR, etc.) is actually not deployed, t=
hen the call to
cargo:undeploy will return a failure indicatin=
g that the deployble to undeploy is not deployed.
To work around the = issue, make sure you define your deployable together with a watchdog. For e= xample:
In that case:
The deployment has failed, with the error returne= d by the deployer and a severity=C2=A0
BUILD FAILU= RE
- If the deployer returns a failure, CARGO will log a message=C2= =A0
The undeployment has failed, with the error returned by the= deployer and a severity=C2=A0
- It will then start= the watchdog, to check if the deployable is not deployed.
- If the w= atchdog detects that the deployable is indeed not deployed, the overall res= ult is a=C2=A0
- If the watchdog detects= that the deployable is still deployed, you then get a=C2=A0
BUILD FAI= LURE
This functionality is available in the Ja= va API, ANT tasks and Maven2/Maven3 plugin.------=_Part_3648_437026217.1369396681925--