As part of the release process, the artifacts are staged in a temporary repository for testing and evaluation before voting. Such repositories are not available by default, so to use them your project must be configured appropriately.
The steps are as follows:
The repository configuration for testing a plugin will typically look something like this (it will be provided in the vote email):
... <pluginRepositories> <pluginRepository> <id>staged-releases</id> <url>http://people.apache.org/~dfabulich/stage-repo</url> </pluginRepository> </pluginRepositories> ...
The important thing is that the staged release does not pollute your eventual environment as it may change if the vote fails and the release is made again. This is why clearing the local repository is necessary, but if you are using a repository manager this is also important to clear. The following provides instructions for setting Archiva up in such a way that the artifacts are isolated already.
These steps will be similar for any repository manager - please refer to their individual documentation for instructions on how to configure remote proxies.
For Archiva, the first step is to create a new managed repository for the staged releases. This will ensure they remain isolated from your environment. On the repositories tab, add a new managed repository with the settings:
Next add a remote repository with settings similar to the following:
Finally, add a proxy connector to connect the two repositories:
You can then utilise this repository from your POM or settings in the same way, but with the alternate URL of http://localhost:8080/archiva/repository/staged-releases/.
The advantage of this approach is that you can usually remove your entire local repository afterwards and after removing the staged repository from your POM the artifacts will no longer be used. There is no need to remove the repository or artifacts from Archiva itself - unless a staged release is updated for further testing.
It is also quite easy to test another staged release at a later date by reusing the repository, or adding a proxy connector and remote repository for a different staging repository.
If you are using the repository mirroring technique to lock down to the repository manager in your environment, you would add an additional mirror to correspond to the additional repository in the POM, such as:
... <mirror> <id>staged-releases-mirror</id> <url>http://localhost:8080/archiva/repository/staged-releases/</url> <mirrorOf>staged-releases</mirrorOf> </mirror> ...
If you regularly test staged releases and want to have a more convenient way to add the repository to a build without modifying your POM, you may add a profile to your POM:
... <profiles> <profile> <id>staged-releases</id> <pluginRepositories> <pluginRepository> <id>staged-releases</id> <url>http://people.apache.org/~dfabulich/stage-repo</url> </pluginRepository> </pluginRepositories> </profile> ...
With this in place, you can activate it by simply changing the plugin version to the one you are testing in the POM as above, then run the build with the following command:
mvn clean install -Pstaged-releases
Note that the same conditions apply as above about cleaning out the local repository to prevent pollution of your local build environment.