[ 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]