[jira] Commented: (MRELEASE-145) release:prepare requires all modules to be SNAPSHOTS

2007-04-25 Thread Emmanuel Venisse (JIRA)

[ 
http://jira.codehaus.org/browse/MRELEASE-145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_94170
 ] 

Emmanuel Venisse commented on MRELEASE-145:
---

No the release project allow to release  a set of projects even if some of them 
aren't SNAPSHOT. For projects that aren't SNAPSHOT, they aren't modified before 
to create the tag, then when the plugin ask for new versions, it's possible to 
set them to SNAPSHOT. The tag created contain all projects that was in the 
reactor.

> release:prepare requires all modules to be SNAPSHOTS
> 
>
> Key: MRELEASE-145
> URL: http://jira.codehaus.org/browse/MRELEASE-145
> Project: Maven 2.x Release Plugin
>  Issue Type: Improvement
>Affects Versions: 2.0-beta-4
>Reporter: Jörg Hohwiller
>Assignee: Emmanuel Venisse
> Fix For: 2.0-beta-5
>
>
> The biggest need for the maven-release-plugin is in complex projects with a 
> lot of modules (that may again have modules). If I do not get it wrong, the 
> current released version forces all modules to be snapshots and releases them 
> individually. This is completely useless in my situation because in the end 
> this forces me to release alle modules together for every change that is to 
> be released and more or less causes that all modules have the same version 
> number. When I call mvn replease:prepare on my toplevel project this is no 
> snapshot, it fails with this error:
> The project : isn't a snapshot ().
> I would expect release:prepare to leave non SNAPSHOT modules untouched (and 
> only verify that they do not have SNAPSHOT dependencies, what should never be 
> the case if the version is no snapshot).
> All reactor projects that have a "-SNAPHSOT" version should be released and 
> theier project-internal dependencies should also be set to the acording 
> released version (and later be set to the new SNAPSHOT).
> Additionally I want to have the complete project to be tagged as a whole 
> instead of each module. This could potentially be configureable (especially 
> which directory is actually tagged, e.g. if the toplevel project is not in 
> trunk/ but somewhere deeper say trunk/develop because other directories in 
> trunk are huge but do not need to be checked out by every developer but need 
> to be tagged).
> I personally think that the best flexibility and final freedom would be to 
> split off the release:prepare goal into 3 goals:
> -create release version(s)
> -create tag(s)
> -update to snapshot version(s)
> These goals could be used individually and one could add some custom steps or 
> replace one with something else.
> For creating the snapshot versions there is also the problem, that you do not 
> know right away which project will be modified when in the future. The 
> coolest thing would be if this would happen automatically when the first 
> change is commited to the module. But this is of cause not praticable in 
> reality (maybe if all commits would be done with maven).

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




[jira] Commented: (MRELEASE-145) release:prepare requires all modules to be SNAPSHOTS

2007-03-22 Thread Parolini Antonio (JIRA)

[ 
http://jira.codehaus.org/browse/MRELEASE-145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_90842
 ] 

Parolini Antonio commented on MRELEASE-145:
---

I agree with Jorg: the release-plugin should be have the ability to make 
partial release without touching the not-snapshot poms.

My workaround for this issue so far as been to use profiles, in order to choose 
what module are released.





> release:prepare requires all modules to be SNAPSHOTS
> 
>
> Key: MRELEASE-145
> URL: http://jira.codehaus.org/browse/MRELEASE-145
> Project: Maven 2.x Release Plugin
>  Issue Type: Improvement
>Affects Versions: 2.0-beta-4
>Reporter: Jörg Hohwiller
>
> The biggest need for the maven-release-plugin is in complex projects with a 
> lot of modules (that may again have modules). If I do not get it wrong, the 
> current released version forces all modules to be snapshots and releases them 
> individually. This is completely useless in my situation because in the end 
> this forces me to release alle modules together for every change that is to 
> be released and more or less causes that all modules have the same version 
> number. When I call mvn replease:prepare on my toplevel project this is no 
> snapshot, it fails with this error:
> The project : isn't a snapshot ().
> I would expect release:prepare to leave non SNAPSHOT modules untouched (and 
> only verify that they do not have SNAPSHOT dependencies, what should never be 
> the case if the version is no snapshot).
> All reactor projects that have a "-SNAPHSOT" version should be released and 
> theier project-internal dependencies should also be set to the acording 
> released version (and later be set to the new SNAPSHOT).
> Additionally I want to have the complete project to be tagged as a whole 
> instead of each module. This could potentially be configureable (especially 
> which directory is actually tagged, e.g. if the toplevel project is not in 
> trunk/ but somewhere deeper say trunk/develop because other directories in 
> trunk are huge but do not need to be checked out by every developer but need 
> to be tagged).
> I personally think that the best flexibility and final freedom would be to 
> split off the release:prepare goal into 3 goals:
> -create release version(s)
> -create tag(s)
> -update to snapshot version(s)
> These goals could be used individually and one could add some custom steps or 
> replace one with something else.
> For creating the snapshot versions there is also the problem, that you do not 
> know right away which project will be modified when in the future. The 
> coolest thing would be if this would happen automatically when the first 
> change is commited to the module. But this is of cause not praticable in 
> reality (maybe if all commits would be done with maven).

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




[jira] Commented: (MRELEASE-145) release:prepare requires all modules to be SNAPSHOTS

2007-03-12 Thread Vincent ASTRUC (JIRA)

[ 
http://jira.codehaus.org/browse/MRELEASE-145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_89837
 ] 

Vincent ASTRUC commented on MRELEASE-145:
-

The solution is to removed the code below in 
org.apache.maven.shared.release.phase.CheckPomPhase

for ( Iterator it = reactorProjects.iterator(); it.hasNext(); )
{
MavenProject project = (MavenProject) it.next();

String projectId = ArtifactUtils.versionlessKey( 
project.getGroupId(), project.getArtifactId() );

if ( !ArtifactUtils.isSnapshot( project.getVersion() ) )
{
throw new ReleaseFailureException(
"The project " + projectId + " isn't a snapshot (" + 
project.getVersion() + ")." );
}
}


> release:prepare requires all modules to be SNAPSHOTS
> 
>
> Key: MRELEASE-145
> URL: http://jira.codehaus.org/browse/MRELEASE-145
> Project: Maven 2.x Release Plugin
>  Issue Type: Improvement
>Affects Versions: 2.0-beta-4
>Reporter: Jörg Hohwiller
>
> The biggest need for the maven-release-plugin is in complex projects with a 
> lot of modules (that may again have modules). If I do not get it wrong, the 
> current released version forces all modules to be snapshots and releases them 
> individually. This is completely useless in my situation because in the end 
> this forces me to release alle modules together for every change that is to 
> be released and more or less causes that all modules have the same version 
> number. When I call mvn replease:prepare on my toplevel project this is no 
> snapshot, it fails with this error:
> The project : isn't a snapshot ().
> I would expect release:prepare to leave non SNAPSHOT modules untouched (and 
> only verify that they do not have SNAPSHOT dependencies, what should never be 
> the case if the version is no snapshot).
> All reactor projects that have a "-SNAPHSOT" version should be released and 
> theier project-internal dependencies should also be set to the acording 
> released version (and later be set to the new SNAPSHOT).
> Additionally I want to have the complete project to be tagged as a whole 
> instead of each module. This could potentially be configureable (especially 
> which directory is actually tagged, e.g. if the toplevel project is not in 
> trunk/ but somewhere deeper say trunk/develop because other directories in 
> trunk are huge but do not need to be checked out by every developer but need 
> to be tagged).
> I personally think that the best flexibility and final freedom would be to 
> split off the release:prepare goal into 3 goals:
> -create release version(s)
> -create tag(s)
> -update to snapshot version(s)
> These goals could be used individually and one could add some custom steps or 
> replace one with something else.
> For creating the snapshot versions there is also the problem, that you do not 
> know right away which project will be modified when in the future. The 
> coolest thing would be if this would happen automatically when the first 
> change is commited to the module. But this is of cause not praticable in 
> reality (maybe if all commits would be done with maven).

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




[jira] Commented: (MRELEASE-145) release:prepare requires all modules to be SNAPSHOTS

2007-01-01 Thread Baerrach bonDierne (JIRA)
[ http://jira.codehaus.org/browse/MRELEASE-145?page=comments#action_83775 ] 

Baerrach bonDierne commented on MRELEASE-145:
-

modules are a convenience so that you can issue the one maven command and have 
it applied to all module projects.

Once you use a module, you are saying "all these files must be released 
together".
If this is not correct, then you should not be using a module, just use a 
regular project with dependencies.

Therefore when you attempt to release your parent project it must be a snapshot 
version. Otherwise you would be overwriting an existing deployed version with 
the version you are about to release and this does not make sense.

> release:prepare requires all modules to be SNAPSHOTS
> 
>
> Key: MRELEASE-145
> URL: http://jira.codehaus.org/browse/MRELEASE-145
> Project: Maven 2.x Release Plugin
>  Issue Type: Improvement
>Affects Versions: 2.0-beta-4
>Reporter: Jörg Hohwiller
>
> The biggest need for the maven-release-plugin is in complex projects with a 
> lot of modules (that may again have modules). If I do not get it wrong, the 
> current released version forces all modules to be snapshots and releases them 
> individually. This is completely useless in my situation because in the end 
> this forces me to release alle modules together for every change that is to 
> be released and more or less causes that all modules have the same version 
> number. When I call mvn replease:prepare on my toplevel project this is no 
> snapshot, it fails with this error:
> The project : isn't a snapshot ().
> I would expect release:prepare to leave non SNAPSHOT modules untouched (and 
> only verify that they do not have SNAPSHOT dependencies, what should never be 
> the case if the version is no snapshot).
> All reactor projects that have a "-SNAPHSOT" version should be released and 
> theier project-internal dependencies should also be set to the acording 
> released version (and later be set to the new SNAPSHOT).
> Additionally I want to have the complete project to be tagged as a whole 
> instead of each module. This could potentially be configureable (especially 
> which directory is actually tagged, e.g. if the toplevel project is not in 
> trunk/ but somewhere deeper say trunk/develop because other directories in 
> trunk are huge but do not need to be checked out by every developer but need 
> to be tagged).
> I personally think that the best flexibility and final freedom would be to 
> split off the release:prepare goal into 3 goals:
> -create release version(s)
> -create tag(s)
> -update to snapshot version(s)
> These goals could be used individually and one could add some custom steps or 
> replace one with something else.
> For creating the snapshot versions there is also the problem, that you do not 
> know right away which project will be modified when in the future. The 
> coolest thing would be if this would happen automatically when the first 
> change is commited to the module. But this is of cause not praticable in 
> reality (maybe if all commits would be done with maven).

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