[
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 <groupId>:<artifactId> isn't a snapshot (<version>).
> 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
