Usage

Basic Configuration

Provide login information in your settings.xml by specifying a server with username and password for the server that is responsible for the ci-management url. 

<server>
  <id>hudson</id>
  <username>username</username>
  <password>password</password>
</server>

Provide a ciManagement in your pom.xml : 

<ciManagement>
  <system>hudson</system>
  <url>http://....</url>
</ciManagement>

Note: The login information is selected by the ci-management server's name or by its URL (in that order).

Moreover a hudson job configuration is needed. There are two ways to create and configure one.

Download and than modify as appropriate a job config.xml from a hudson server e.g. via 

scp www.example.com:/home/tomcatuser/.hudson/jobs/examplejob/config.xml

Use your browser to download and than modify one from e.g. 

http://www.example.com/hudson/job/examplejob/config.xml

Using the manual configuration option:

Copy the downloaded file to ${project.home}/src/ci/config.xml and configure the plugin by using this configuration: 

<configuration>
  <ciServerId>hudsonId</ciServerId>
  <jobConfigFile>${project.home}/src/ci/config.xml</jobConfigFile>
  <jobName>jobname</jobName>
</configuration>
Than execute one of the jobs from below. The manual option allows you to handle one hudson job with the given name.

Using the ci-config option:

Create a ci-config.xml like this one: 

<ci-config>
  <import-definitions>
    <import-definition id="default">
      <import>config</import>
    </import-definition>
  </import-definitions>
</ci-config>
The ci-config option allows you to handle one hudson job for each import-definition of your ci-config file. So is possible to use multiple import-definition entries with more than one import entry. For each import-definition one job will be tampered. All files specified by an import will be merged in the order they are given. The last having the precedence. Even parent projects having a ci-config with the same id will be used. The name of the files must be the value of the import tag ending with .xml for the id default and with -$id.xml for any other import-definition e.g.: config-site.xml . The used jobName will be the projects name with the same id as postfix.

Advanced Configuration

It is possible to declare a dependency that contains config.xml files that can be used in the ci-config.xml import statements. 

<plugin>
          <groupId>de.smartics.ci</groupId>
          <artifactId>hudson-maven-plugin</artifactId>
          <version>${project.version}</version>
          <dependencies>
            <dependency>
              <groupId>de.smartics.config</groupId>
              <artifactId>config-smartics-hudson</artifactId>
              <version>some.version</version>
            </dependency>
          </dependencies>
        </plugin>
The artifact de.smartics.config:config-smartics-hudson contains the config.xml files we want to use.

For real life examples see the source-code of our pom-root (see especially the pom.xml with te plugin declaration and the src/etc/ directory) with the configuration, our config-smartics-hudson with our company wide config.xml files and this project hudson-maven-plugin (see especially the src/etc/ci/ directory) using the above config

What happens really

When using the ci-config method to configure this plugin.For each import-definition a hudson job is addressed (e.g. in the case of hudson:createJobs for each one a new hudon job will be created.).

But which configuration will be used? All import s of one import-definition will be merged to one config.xml . The import files will be searched in the classpath (this enables you to add a jar-file containing config.xml files to the configuration/dependency of this plugin, as explained above).

Some sections of the config.xml will be generated on the fly by this plugin, when they can not be found in the merged config.xml .

These are:

The description : using the project description of the pom.xml .

The authentication token to execute a build using a script : using the name of the job. The name of the job is the project.name followed by the id of the import-definition . The only exception is, that default will be omitted.

The scm entry : using the project scm definition of the pom.xml . Rightnow only subversion is supported

Description of the available jobs

Create hudson jobs

To add new hudson jobs on the ci-management system from the projects data, run: 

mvn ${project.groupId}:${project.artifactId}:${project.version}:createJobs

Or add the following configuration to your POM: 

<pluginManagement>
  <plugins>
    <plugin>
      <groupId>${project.groupId}</groupId>
      <artifactId>project.artifactId</artifactId>
      <version>${project.version}</version>
    </plugin>
  </plugins>
</pluginManagement>

With this configuration you may create new jobs on the hudson server without any arguments (short version): 

mvn hudson:createJobs

Update hudson jobs

Analog to create jobs, jobs can be updated by 

mvn hudson:updateJobs

Delete hudson jobs

Analog to create jobs, jobs can be deleted by 

mvn hudson:deleteJobs

Enable hudson jobs

Analog to create jobs, jobs can be enabled (if disabled) by 

mvn hudson:enabledJobs

Disable hudson jobs

Analog to create jobs, jobs can be disabled (if enabled) by 

mvn hudson:disableJobs

Check hudson jobs

Checks if a job exists. 

mvn hudson:checkJobs