maven-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain MariƩ (JIRA) <j...@codehaus.org>
Subject [jira] Issue Comment Edited: (MRELEASE-252) Support for multi modules project
Date Tue, 24 Mar 2009 10:27:13 GMT

    [ 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

       

Mime
View raw message