maven-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Arnaud Heritier (JIRA)" <j...@codehaus.org>
Subject [jira] Updated: (MRELEASE-391) Improve staging support
Date Mon, 24 Nov 2008 22:47:19 GMT

     [ http://jira.codehaus.org/browse/MRELEASE-391?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Arnaud Heritier updated MRELEASE-391:
-------------------------------------

    Description: 
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 : http://blogs.sonatype.com/people/brian/2008/11/20/announcing-nexus-maven-repository-manager-pro-beta/
:-) )
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
necessary).


  was:
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.
For that part we have the stage plugin, which 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
necessary).



> Improve staging support
> -----------------------
>
>                 Key: MRELEASE-391
>                 URL: http://jira.codehaus.org/browse/MRELEASE-391
>             Project: Maven 2.x Release Plugin
>          Issue Type: New Feature
>    Affects Versions: 2.0-beta-8
>            Reporter: Arnaud Heritier
>
> 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 : http://blogs.sonatype.com/people/brian/2008/11/20/announcing-nexus-maven-repository-manager-pro-beta/
:-) )
> 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
necessary).

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message