Mailing-List: contact issues-help@maven.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@maven.apache.org
Received-SPF: neutral (herse.apache.org: local policy)
Message-ID: 
 <98800241.1162788572694.JavaMail.haus-jira@codehaus01.managed.contegix.com>
Date: Sun, 5 Nov 2006 22:49:32 -0600 (CST)
From: "Brett Porter (JIRA)" <jira@codehaus.org>
To: issues@maven.apache.org
Subject: [jira] Updated: (MRELEASE-145) release:prepare requires all modules
 to be SNAPSHOTS
In-Reply-To: 
 <23604071.1154603641609.JavaMail.haus-jira@codehaus01.managed.contegix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

     [ http://jira.codehaus.org/browse/MRELEASE-145?page=3Dall ]

Brett Porter updated MRELEASE-145:
----------------------------------

    Affects Version/s: 2.0-beta-4
        Fix Version/s:     (was: 2.0-beta-4)

> 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=F6rg 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 release=
s them individually. This is completely useless in my situation because in =
the end this forces me to release alle modules together for every change th=
at 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 th=
is 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 (a=
nd only verify that they do not have SNAPSHOT dependencies, what should nev=
er be the case if the version is no snapshot).
> All reactor projects that have a "-SNAPHSOT" version should be released a=
nd 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 ne=
ed to be tagged).
> I personally think that the best flexibility and final freedom would be t=
o 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 step=
s 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 c=
hange is commited to the module. But this is of cause not praticable in rea=
lity (maybe if all commits would be done with maven).

--=20
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: htt=
p://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira