[
http://jira.codehaus.org/browse/MRELEASE-252?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=170410#action_170410
]
Sylvain Marié edited comment on MRELEASE-252 at 3/24/09 5:26 AM:
-----------------------------------------------------------------
Below is a sum-up of our common requirements and decisions so far. Please don't
hesitate to email me or post a comment so that I update this list, if things
are wrong or missing.
h4. Entry point of the maven-release command [EP]:
# One maven project (may be a simple project, an aggregator or a parent). This
is because all traditional maven command have one project as an entry point.
# Should handle standard hierarchical structure (parent/aggregator pom in root
dir) as well as flat structure (parent/aggregator pom in its own dir)
h4. Impacted source files ( [sources] ):
I think we all agree that this is limited to the SCM where the entry point
lies, for obvious simplicity reasons, and also because the only way for a "mvn
install" to work on a fresh checkout of the entry point is that all sub-modules
are part of the checkout as well, so are part of the same SCM.
h4. Impacted maven projects ( [projects], subset of [sources])
# From the entry point [EP], retrieve a list of maven projects
#* from the aggregation graph
#* from the dependency graph (not relevant imo because we should play in a
subscope of mvn install, but this point is still open)
# Other maven projects that would be part of [sources] are not considered
h4. Released projects ( [released], subset of [projects] ):
# The user can choose which of all the [projects] will be released. see chapter
about configuration
h4. Pom updates (for SCM TAG):
# for each of the [released] projects, update its pom
#* update its version (release version)
#* update the reference to the parent module if it is in [released]
#* update the dependencies to other [released] modules
# for each project in [unreleased]=[projects]-[released] update its pom
#* update the reference to the parent module if it is in [released]
#* update the dependencies to other [released] modules
h4. SCM TAG
# The release process should work even if TAGs can not be partially made (Git)
# a checkout from the TAG should be able to build (mvn install)! It is actually
required by the release-perform step. So all projects required for a mvn
install on the entry point should be here, even if they are not released.
h4. Pom updates (New SCM TRUNK):
# for each of the [released] projects, update its pom
#* update its version (new snapshot version)
#* update the reference to the parent module if it is in [released]
#* update the dependencies to other [released] modules
# for each project in [unreleased]=[projects]-[released] update its pom
#* update the reference to the parent module if it is in [released]
#* update the dependencies to other [released] modules
h4. Deployment of release in repository
No new relevant requirement.
h4. Configuration to define groupId/artifactId and target release version of
all modules to be released
# interactive configuration: when input is needed during the process, just ask
(release or not? release version ? next trunk version?)
# file-based configuration
#* in the pom, define "release sets" under maven-release configuration and
activate them with commandline or profiles
#* in release.properties
#* external file, e.g. XML-based. File selected using a command-line argument
or in pom configuration
# the brand new -pl opion of maven 2.1.0 could also probably help us here
was (Author: slysha):
Below is a sum-up of our common requirements and decisions so far. Please
don't hesitate to email me or post a comment so that I update this list, if
things are wrong or missing.
h4. Entry point of the maven-release command [EP]:
# One maven project (may be a simple project, an aggregator or a parent). This
is because all traditional maven command have one project as an entry point.
# Should handle standard hierarchical structure (parent/aggregator pom in root
dir) as well as flat structure (parent/aggregator pom in its own dir)
h4. Impacted source files ( [sources] ):
I think we all agree that this is limited to the SCM where the entry point
lies, for obvious simplicity reasons, and also because the only way for a "mvn
install" to work on a fresh checkout of the entry point is that all sub-modules
are part of the checkout as well, so are part of the same SCM.
h4. Impacted maven projects ( [projects], subset of [sources])
# From the entry point [EP], retrieve a list of maven projects
#* from the aggregation graph
#* from the dependency graph (not relevant imo because we should play in a
subscope of mvn install, but this point is still open)
# Other maven projects that would be part of [sources] are not considered
h4. Released projects ( [released], subset of [projects] ):
# The user can choose which of all the [projects] will be released. see chapter
about configuration
h4. Pom updates (for SCM TAG):
# for each of the [released] projects, update its pom
#* update its version (release version)
#* update the reference to the parent module if it is in [released]
#* update the dependencies to other [released] modules
# for each project in [unreleased]=[projects]-[released] update its pom
#* update the reference to the parent module if it is in [released]
#* update the dependencies to other [released] modules
h4. SCM TAG
# The release process should work even if TAGs can not be partially made (Git)
# a checkout from the TAG should be able to build (mvn install)! It is actually
required by the release-perform step. So all projects required for a mvn
install on the entry point should be here, even if they are not released.
h4. Pom updates (New SCM TRUNK):
# for each of the [released] projects, update its pom
#* update its version (new snapshot version)
#* update the reference to the parent module if it is in [released]
#* update the dependencies to other [released] modules
# for each project in [unreleased]=[projects]-[released] update its pom
#* update the reference to the parent module if it is in [released]
#* update the dependencies to other [released] modules
h4. Deployment of release in repository
No new relevant requirement.
h4. Configuration to define groupId/artifactId and target release version of
all modules to be released
# interactive configuration: when input is needed during the process, just ask
(release or not? release version ? next trunk version?)
# file-based configuration
#* in the pom, define "release sets" under maven-release configuration and
activate them with commandline or profiles
#* in release.properties
#* external file, e.g. XML-based. File selected using a command-line argument
or in pom configuration
> Support for multi modules project
> ---------------------------------
>
> Key: MRELEASE-252
> URL: http://jira.codehaus.org/browse/MRELEASE-252
> Project: Maven 2.x Release Plugin
> Issue Type: Improvement
> Components: perform, prepare, stage
> Affects Versions: 2.0-beta-6
> Environment: Maven 2.0.6
> Reporter: Franck HUGOT
>
> I would like to prepare a release for multi-modules project.
> I would create tags for all the modules and modify poms.
> Not only the versionId in the pom but also the eventual dependencies between
> all the modules.
> Indeed, if a module A has a dependency to module B, the version will be
> updated.
> The dependency management is a hard task in multi modules project and this
> feature would be really appreciated.
--
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
