français

Table of Contents Packaging, staging, and releasing Maven Artifacts for WET Prerequisites (assuming Windows) WET Maven Artifact Generation Additional information & comments Contents of settings.xml

These steps only need to be done once:

1. Get latest version of Maven (maven.apache.org) and install it. Download & extract, just like Ant, and add the Maven/bin folder to your path.
2. Sign up for a Sonatype Nexus account by following the instructions here.
3. Get someone to grant you permissions to the WET Nexus repository.
4. Create a Maven settings.xml file under your <user home>/.m2 folder (create it if it doesn't exist). See Contents of settings.xml.
5. Download and install Gpg4win.
6. Using Kleopatra (comes with Gpg4win), import the WET private key. This can be done by issuing the command 'gpg --import wet_private.key'

The process has been broken down into these basic steps:

Pre: WET Ant build is first run, making dist folder available.

1. Package and stage by running 'mavenStage.cmd'. It will prompt for the required arguments if you don't give it any.
   1. Using the stuff from dist, script creates the WAR packages for each of the Maven overlays.
   2. During this script, you will be prompted to enter the PGP passphrase for signing the artifacts. The script will error out if you provide the wrong password.
   3. These WARs are uploaded to the Sonatype Nexus repository (this part takes a while!)
   4. Using the contents of each of the WAR overlays and theme demo folders, script creates a set of test folders in the location of your choosing (recommend outside your Git repo)
2. If desired, a quick smoke test can be done by accessing the test files created in Step 1.4.
3. Once satisfied, release the artifacts by running 'mavenRelease.cmd'. Be sure. Once released to Maven Central, you can't UNrelease!
4. Commit modified Maven files that now contain new version information, along with the rest of the things you commit.

Exceptional flow: If something goes really wrong and smoke test convinces you to abort entirely, you should run the 'mavenDrop.cmd' script to drop the Sonatype repository.

Post: You can run setVersion.cmd afterward, to set the prerelease version of the next release. Maven has a convention that should be followed where prerelease version has -SNAPSHOT appended, i.e. 4.0-SNAPSHOT. The setVersion.cmd script could also be altered to use a flag to drive whether -SNAPSHOT gets appended. You can use setVersion.cmd any time you create a branch for a new version, to set the version of the Maven artifacts for that branch. This could be a useful hook for further automation.

• Currently the Maven projects are configured to be used in both of the following scenarios:
  1. As part of your release branch, with the 'maven' folder residing under /build
  2. As part of the dist tag, with 'maven' folder being a sibling of 'demo' and 'dist'.

  In the first case, the relative paths used by Maven will be controlled by the mavenStage.cmd script.

  In the second case, relative paths will be governed by defaults that reside within the Maven pom file.

• If the contents of any of the themes is altered significantly i.e. different folders are included, then someone will need to edit the Maven pom.xml files to point to the new folders.
• Along the same line, if a new theme is added, the Maven files will need to be updated.

Contents of the settings.xml file should be like this (insert the proper password):

 <settings>
    <servers>
        <server>
            <id>sonatype-nexus-snapshots</id>
            <username>INSERT_YOUR_NEXUS_USERNAME_HERE</username>
            <password>INSERT_PASSWORD_HERE</password>
        </server>
        <server>
            <id>sonatype-nexus-staging</id>
            <username>INSERT_YOUR_NEXUS_USERNAME_HERE</username>
            <password>INSERT_PASSWORD_HERE</password>
        </server>
    </servers>
 </settings>