maven-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Arnaud Heritier (JIRA)" <>
Subject [jira] Updated: (MRELEASE-391) Improve staging support
Date Wed, 26 Nov 2008 11:30:20 GMT


Arnaud Heritier updated MRELEASE-391:

    Remaining Estimate: 3 days
     Original Estimate: 3 days

> Improve staging support
> -----------------------
>                 Key: MRELEASE-391
>                 URL:
>             Project: Maven 2.x Release Plugin
>          Issue Type: New Feature
>    Affects Versions: 2.0-beta-8
>            Reporter: Arnaud Heritier
>   Original Estimate: 3 days
>  Remaining Estimate: 3 days
> By default the plugin with release:prepare and release:perform deploys project's artifacts
and website in the final location.
> release:prepare and release:stage mojos deploys them in a staging environment to validate
the before the submission in the final environment.
> The problem is that we have nothing in the release plugin to move artifacts (and website)
from the staging environment to the final one.
> In my case I would like to have only one staging repository (and not one for each release
like actually). (And I don't have -yet - nexus with its support for staging operations :
:-) )
> The stage plugin has several limitations. We cannot select which groupId/artifactId/version
to copy (the entire repository is copied) and even if we could define them this plugin cannot
know which artifacts were deployed in the release:stage mojo.
> I propose to add a mojo (release:record-artifacts) called by release:stage to record
all artifacts deployed. We could append it in goals called by the mojo in the forked maven
launch. The mojo will create a file (properties or xml) where it stores all artifacts attached
in the project and deployed in the staging environment. At the end of the release:stage mojo,
this file will be deployed to the staging repository within the reactor groupId/artifactId/version
used to release the project (or we can store it only locally like the release:properties file,
but it could be useful to allow someone else than the one who staged deliveries to publish
in the final repository).
> We add another mojo (release:publish) which downloads the list of artifacts. After parsing
it it download all artifacts and deploy them in the final repository (merging metadata if

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
For more information on JIRA, see:


View raw message