citadel.nodes.maven module

class citadel.nodes.maven.Maven(yml, path)

Synopsis:Run Maven for either generating or publishing an artifact. Requirements:None Platform:Any

The maven module may be used both for building a project and publishing an artifact. The publishing means that the files will be uploaded to a standard maven repository following all of its conventions.

Since a maven build may generate multiple artifacts, typically impossible to correctly assess without fully running the reactor, it’s left to the user which ones should actually be published.

As such, it’s discouraged (though in no way forbidden) to use a lifecycle such as “clean deploy”, thus allowing each artifact published explicitly at the publish stage without errors since, in the case of non-snapshot repositories, no duplicate versions are allowed.

Build

Parameters:

• pom (optional) – The pom file to be used.
• lifecycle (optional) – The lifecycle stages to be run (default: clean assemble).
• opts (optional) – Additional maven options.

Usage

build:
  maven:
    lifecycle: clean install

By default, the pom.xml file that exists in the same directory of the citadel.yml file will be invoked. If any other file is meant to be executed, the pom directive should be used.

Take into account that the normal maven behaviour is look for a settings XML file in the $USER directory (/home/user/.m2/settings.xml).

Since the build typically requires downloading artifacts from remote repositories, the settings.xml can be overridden using the opts directive:

build:
  maven:
    lifecycle: clean install
    pom: anotherpom.xml
    opts: -s special.settings.xml

Additional options may be passed and will be treated as standard options for the maven executable. As such, the following example:

build:
  maven:
    lifecycle: clean install
    skipTests: True
    another.option: SomeValue

Would be translated as:

mvn -f pom.xml -DskipTests=True -Danother.option=SomeValue

Publish

Parameters:

• file (required) – The file to be uploaded.
• artifactId (required) – The artifact’s ID to be published with.
• groupId (required) – The artifact’s group ID to be published with.
• version (optional) – The version of the artifact being published.
• snapshot (optional) – Whether the artifact should be published as SNAPSHOT.
• opts (optional) – Additionl options being passed to maven.

Usage

publish:
  - maven:
      file: target/artifact*.jar
      artifactId: myArtifact
      groupId: com.company.project
  - maven:
      file: target/anotherArtifact*.jar
      artifactId: SpecialProject
      groupId: com.company.project

The deploy option from maven should NOT be confused with the actual deployment procedure of citadel. Within the maven context, deploy typically (may be overriden) means uploading the artifacts to a maven-compliant repository.

Using a standard configuration, deploy in maven is the direct equivalent to citadel’s publish.

Using maven within the publish directive provides the option of segregating the build and publish stages. The reasoning behind this separation is that it may be useful for Continuous Integration environments to run the builds without side effects (in this case, uploading artifacts).

Underneath, this uses maven’s deploy:deploy (<plugin>:<goal>). The maven executable being used is whatever comes up by running the which command.

If no version is specified, citadel will attempt to induce the artifact’s version. The heuristic is based on whatever the user sets in the file directive and a few pre-established conventions. Currently, citadel supports reading versions from the following types:

• apk (Android)
• jar/war/ear (Java Archive)
• car (Carbon Archive)
• ipa (iOS)
• rpm (RedHat Package Manager)

If any other file extension is used, citadel will abort stating it’s unable to recognize the file’s format (contributions are welcome!).

The recommended behaviour is to let citadel induce the artifact’s version, thus avoiding multiple files being changed whenever your application’s versioning changes.

If multiple artifacts are to be deployed, a yaml list should be constructed instead of the plain key:value map.

Any unrecognized options will be translated into -Doption=value.

As such, the following:

publish:
  maven:
    file: target/artifact.*.jar
    artifactId: myArtifact
    groupId: com.company.project
    snapshot: True
    opts: special.settings.xml

Would get translated as:

FILE=$(find target -type f -print | grep -E "target/artifact.*.jar")
VERSION=$(unzip -p '$FILE'             '*com.company.project*/*myArtifact*/pom.properties'             | grep version             | awk -F= '{print $2}')
mvn deploy:deploy-file \
    -Dfile="$FILE-SNAPSHOT" \ # Snapshot == True adds the -SNAPSHOT suffix
    -Dversion="$VERSION" \
    -DartifactId="myArtifact" \
    -DgroupId="com.company.project" \
    -s special.settings.xml -V -B -U

read_apk_version(artifact)

Read version from an APK file.

read_car_version(artifact)

Read version from a CAR file.

read_ipa_version()

Thanks Steve.

read_jar_version(artifact, group_id, artifact_id)

Read version from a JAR file.

read_rpm_version(artifact)

Read version from an RPM file.