Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 112 Next »

A Maven 2 plugin that wraps the Cargo Java API

Functional tests

Icon

The usage of Cargo for executing functional tests on a container do not need this m2 plugin. You should directly use the Cargo Java API from your Java unit test classes (JUnit, TestNG, etc), as described on http://tinyurl.com/btmwa.

Table of Contents

This page documents the following:

  • Installation: explains how to install the plugin
  • Features: explains how to use the plugin on several use cases
  • Configuration: provide reference documentation for all configuration options
  • Tips: tips for using the plugin

Installation

There is no installation necessary. The Cargo artifacts are hosted on ibiblio.

Note that the Cargo project has a snapshot repository on Codehaus. If you want use snapshot versions of the Cargo m2 plugin you'll need to add this definition in your POM or settings file:

Features

As usual the best way to learn to use a tool is through examples. We have several sample projects that we use as our internal functional tests suite. We'd really recommend that you check them out. In addition here are the typical uses cases covered by the plugin:

Goals

Description

cargo:start

Start a container and optionally deploy deployables (WAR, EAR, etc)

cargo:stop

Stop a container

cargo:deploy

Deploy a J2EE archive to a running container

cargo:undeploy

Undeploy a J2EE archive from a running container


The configuration elements are described in the configuration section.

Configuration

Work in progress...

Icon

This section is not finished and does not represent the full list of configuration options. In the meantime please check the samples on this page for examples of configurations.

Top level configuration elements

Description

Default value

<configuration>

Definition of a Configuration

No default, cannot call cargo:start or cargo:stop if not defined

<container>

Definition of a Container

Defaults to a Jetty 5.x container if not specified

<deployer>

Definition of a Deployer

No default, cannot call cargo:deploy and cargo:undeploy if not defined

<container> elements

Description

Default value

<append>

If true then the file specified by <output> will not be erased across different runs.

False

<containerId>

Id of the container to use. Valid values can be found in the description page for each container

jetty5xEmbedded

<dependencies>

List of extra dependencies that will be added to the container execution classpath

No default

<home>

Location where the container is installed

No default, must define either a zipUrlInstaller or a home element

<implementation>

Full classname of a custom container implementation to use. In that case, the custom container is registered with the <containerId> and <type> specified

No default

<log>

Path to a file where Cargo logs are saved

No logs are saved

<output>

Path to a file where container logs are saved.

No logs are saved

<type>

Container's type. Valid values are local, remote.

local

<zipUrlInstaller>

Defines the location of a container distribution zip that will be downloaded and installed.

No default, a home directory for the container has to be defined in that case

<configuration> elements

Description

Default value

<deployables>

TODO

TODO

<dir>

TODO

TODO

<implementation>

TODO

TODO

<properties>

TODO

TODO

<type>

TODO

TODO

<deployer> elements

Description

Default value

<deployables>

TODO

TODO

<implementation>

TODO

TODO

<type>

TODO

TODO

Tips

Starting mutiple containers conditionally

Maven 2 supports the notion of profiles which can be used with Cargo to decide for example when to run tests on a specific container. Here's how you could use the Cargo m2 plugin to that effect:

Then to start the tomcat 5.x container you would type mvn -P tomcat5x integration-test. if you want to start both containers you would type mvn -P tomcat5x,orion2x integration-test.

If you want to define a profile as the default you can use the <activation> element with an activation strategy. For example if you want a profile to be always on, use:

TODO: Show how to share configuration data between profiles (this should work by defining the default config data in the <build> element).

  • No labels