[ http://jira.codehaus.org/browse/MNG-607?page=comments#action_43137 ]
John Casey commented on MNG-607:
--------------------------------
My plan for implemetation (comments are welcome):
=============================================================================
MNG-607: release-pom handling
Goals
------------------------
PRIMARY
* Support fully reproducible builds for releases
* Support rebuilding releases from tagged SCM checkouts
SECONDARY
* Provide concrete information about how an artifact was created
Requirements
------------------------
* fully resolved release-pom.xml should be created in ${pom.build.directory}
during package
- should EXPLICITLY define all information inherited/implied by the
normal pom.xml, with no expressions.
- all RELEASE/LATEST/SNAPSHOT/range metadata should be resolved to
concrete versions
- release-pom.xml should be archived in the artifact, rather than
the original pom.xml
* release plugin execution should manage this release-pom.xml alongside the
original pom.xml, and tag appropriately
- should be committed and tagged with the release
- should then be deleted before next (-SNAPSHOT) pom.xml version is
committed
* execution of subsequent builds should try first to use release-pom.xml
- default over to pom.xml if non-existent
- NOTIFY the user when using release-pom.xml
- allow '-f' switch to force use of pom.xml (or other pom file) when
release-pom.xml exists
Implementation
---------------------
* Add getFullyResolvedModel():Model to some sort of utility component
(DefaultMavenProjectBuilder, MavenProject, etc. ?)
- sort through plugins and resolve to concrete version
- sort through dependencies and resolve to concrete version
- remove dependencyManagement and pluginManagement (not used in
fully-resolved scenario)
- cache this Model instance for later reuse?
* Change MavenArchiver to use ${project.fullyResolvedModel} for the bundled
pom.xml in META-INF
* Change release plugin to write, tag/commit, delete, commit release-pom.xml
using ${project.fullyResolvedModel} to ${basedir}/release-pom.xml.
* Modify MavenCli:
- pickup on release-pom.xml if it exists, and NOTIFY THE USER that it's
using that pom.
- provide '-f' switch for explicitly specifying which pom file to use (for
overriding release-pom.xml selection)
Plan of Attack
-----------------------
1. Implement getFullyResolvedModel():Model with caching in MavenProject(?)
2. Modify MavenArchiver to use fully resolved model in META-INF
3. Modify MavenCli to support '-f' and choice of release-pom.xml over pom.xml
4. Modify release plugin to support management of release-pom.xml
> implement release-pom.xml from design docs
> ------------------------------------------
>
> Key: MNG-607
> URL: http://jira.codehaus.org/browse/MNG-607
> Project: Maven 2
> Type: New Feature
> Components: maven-plugins, maven-core
> Reporter: Brett Porter
> Assignee: John Casey
> Priority: Blocker
> Fix For: 2.0-beta-1
>
>
> 2 components to this:
> - writing the pom during the release plugin and doing the scm operations
> - using it instead when present at build time, instead of pom.xml
> For the second, I'm not sure if this should be automatic or controlled by a
> -f switch. I think it should be automatic, and the -f switch should be
> implemented to allow pom.xml to be used when release-pom.xml is there. (As
> well as other pom files).
> Design:
> http://docs.codehaus.org/display/MAVEN/Dependency+Mediation+and+Conflict+Resolution
--
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
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
