re [1] - I feel like it can, or at least *should*. I'll take a look
tomorrow...

A.


On Thu, Nov 14, 2013 at 5:55 PM, Andrew Phillips <[email protected]>wrote:

> That is something that could be useful, but if I am not wrong, we haven't
>> needed that yet.
>>
>
> I fear we actually need and use that every time we make a release, because
> of the way the projects are split across different repos and Maven "trees"
> :-(
>
> The problem we had for 1.6.2-incubating was as follows: at the start of a
> release, we first do the main jclouds repo, which results in a jclouds
> project POM version of X.Y.Z (no SNAPSHOT).
>
> The next release would be e.g. for jclouds-labs. If jclouds-labs inherits
> its version straight from jclouds-project, we have to leave jclouds-project
> at X.Y.Z-SNAPSHOT, because otherwise jclouds-labs is no longer a snapshot
> version and so can't be released [1].
>
> But we obviously want the released version of jclouds-labs to inherit from
> the *released* version of jclouds-project, so we need to set the
> jclouds-project dependency to X.Y.Z and keep the version of jclouds-labs at
> X.Y.Z-SNAPSHOT *ar the same time*.
>
> Then, if we run the release for jclouds-labs and it still has dependencies
> on snapshot core deps (which it will if they use ${project.version}, which
> is still a snapshot version), the release plugin prompts you 1,000,001
> times for the release version you want to use, which makes the release
> process really painful - at least, it was for 1.6.2-incubating.
>
> Setting the version of the parent POM and all the core deps to the release
> version in one commit seems much easier. If we can find a way to do that
> without a separate variable for the core dep version, all the better.
>
> Of course, if we find a way to get the Maven release plugin to "play nice"
> and handle all the version updates of deps outside the current reactor
> during the release, that would be ideal.
>
> ap
>
> [1] I don't know if the Maven release plugin can prompt you to update the
> *parent* POM version as it does for snapshot dependencies - we should check
> this!
>

Reply via email to