Cargo : Deploying to a running container This page last changed on Feb 07, 2006 by vmassol. Cargo supports deploying to an already running container. This feature is called hot deployment). You call it by using the (`cargo:deploy`) goal (e.g. `mvn cargo:deploy`). Note that you can also do static deployment by simply defining the deployables to deploy in the `<configuration>` element as shown in the Starting and stopping a container tutorial. In that case the deployables 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 container use case.
### Using a local deployer A local deployer is a deployer that deploys deployables 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 `<containerId>`. You can check that by reviewing the supported container list and selecting the container you wish to use. Example of doing a local deploy to an existing configuration:
    [...]
    <configuration>

      <!-- Container configuration -->
      <container>
        <containerId>resin3x</containerId>
        <home>c:/apps/resin-3.0.9</home> or
        <zipUrlInstaller>
          <url>http://www.caucho.com/download/resin-3.0.9.zip</url>
          <installDir>$\{basedir}/target/install</installDir>
        </zipUrlInstaller>
      </container>

      <!-- Configuration to use with the container -->
      <configuration>
        <type>existing</type>
        <properties>
          [...]
        </properties>
      </configuration>

      <!-- Deployer configuration -->
      <deployer>
        <type>local</type>
        <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>
          </deployable>
          <deployable>
            <groupId>ear group id</groupId>
            <artifactId>ear artifact id</artifactId>
            <type>ear</type>
            <pingURL>optional url to ping to know if deployable is done or not</pingURL>
          </deployable>
          [...]
        </deployables>
      </deployer>

    </configuration>
    [...]
As for the `cargo:start` goal if your project is a J2EE project then the generated artifact will be automatically added to the list of deployables to deploy. ### Using a remote deployer 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 Cargo). Thus you'll need to use an id for a remote container in `<containerId>` and a runtime configuration. Example of doing a remote deploy using a runtime configuration:
    [...]
    <configuration>

      <container>
        <containerId>tomcat5x</containerId>
        <type>remote</type>
      </container>

      <configuration>
        <type>runtime</type>
        <properties>
          <cargo.remote.username>username</cargo.remote.username>
          <cargo.remote.password>password</cargo.remote.password>
        </properties>
      </configuration>

      <deployer>
        <type>remote</type>
        <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>
          </deployable>
          [...]
        </deployables>
      </deployer>

    </configuration>
    [...]
As you can see the information to connect and do the deployment to the remote container is specified in the runtime configuration (`cargo.remote.username` and `cargo.remote.password`). The properties to define are deployer-dependent. (TODO: Add link to reference documentation for specific remote deployers once it exists...) Here's an another example, this time deploying the current project's artifact to a running JBoss container using a default 8080 port and default authorizations (note this example requires version 0.2 of the Maven plugin):
    [...]
    <configuration>
      <container>
        <containerId>jboss4x</containerId>
        <type>remote</type>
      </container>
    </configuration>
    [...]
Just type `mvn cargo:deploy`. Notice that we haven't specified a `<deployer>` element nor a `<configuration>` one. This is because the plugin is smart enough to create default instances for you. Cool, isn't it?

Document generated by Confluence on Mar 22, 2006 15:28