Mailing-List: contact dev-help@aries.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@aries.apache.org
Received-SPF: pass (athena.apache.org: domain of
 holly.k.cummins@googlemail.com designates 74.125.82.48 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <3467161.GffQqEhxtM@dilbert.dankulp.com>
References: 
 <CAC9tjn_Zno1etz-3cwhhvSGATrLGBxrNyNVYWXhhxHM=xUys5A@mail.gmail.com>
	<3467161.GffQqEhxtM@dilbert.dankulp.com>
Date: Tue, 29 May 2012 22:49:22 +0100
Message-ID: 
 <CAC9tjn9wEbRU4wjud-dWzbj+9UJDx-jbgkHRh5HQ7kakj91jLA@mail.gmail.com>
Subject: Re: Build stability, parent changes, and build #1469
From: Holly Cummins <holly.k.cummins@googlemail.com>
To: dev@aries.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Tue, May 29, 2012 at 8:09 PM, Daniel Kulp <dkulp@apache.org> wrote:

I wrote:

[snip]

>> Unfortunately, we now have fourteen test failures which will need to
>> be fixed before 1.0.0 work can progress.
>

Dan wrote:

> Except the tests actually PASS on my machine with the changes. =A0 That
> certainly makes it difficult to figure out what's causing it. =A0 Likely
> something more timing related, but I'm not really sure yet.

Hi Dan, I'm sorry if my note was grumpy. I'm beginning to despair of
ever getting green builds and getting the 1.0.0 release out the door.
I'd assumed that things had worked for you locally for you if you'd
delivered. The difficulty of figuring out what's causing the failures
is what I was driving at with my comments about not delivering to a
broken build. Because there were already test failures, it's harder to
unpick what's going on with the latest batch of failures. It's also
harder for Brian to fix the problems related to ARIES-832 if other
tests are now breaking. I wasn't suggesting that you shouldn't have
broken the build at all, since of course these things happen. (I'd be
in a bit of a glass house, since I broke the build the other week too,
again because things behaved differently on Jenkins.)

Confusingly, build 1470 is back down to two failures, and the
ARIES-858 changes delivered on 1470 should have improved concurrency
but not changed any test results. I'm wondering if we're seeing some
interaction between the artefacts produced by the Aries builds,or
something subtle like that.

I'll move the discussion of release version numbers to a new thread,
since I think it's a broader issue.

Holly


>
>
>> Ironically, I've been waiting
>> (for a week) for a clean build, so that I can deliver changes very
>> similar to the ones which Dan's made
>> (https://builds.apache.org/job/Aries/1469/changes). Dan's changes
>> switch from using the snapshot parents to the released parents, which
>> allows a build to be done without building parent first.
>
> Well, the main reason is that it actually allows the SNAPSHOTs of things
> like blueprint and transaction and such that we deploy to the snapshot
> repository to actually be usable. =A0 =A0 Without the change, you cannot =
build
> things like Karaf/trunk (which uses those snapshots right now) without fi=
rst
> building Aries locally. =A0 More in a sec.....

So does this mean that we'll never be able to try out the latest
version of the parent poms without doing a parent release before we
switch to them? This doesn't seem ideal to me. However, I don't think
I really understand the issue. What do you mean by 'allowing'
SNAPSHOTs of blueprint? Do you mean download these snapshots from a
repo, or build them as part of the build of another project?

[snip]
>
> This is only partially for this reason. =A0 It's mostly to get the deploy=
ed
> snapshots to actually be usable for other projects to continue testing th=
em.
> Nexus does NOT allow a snapshot version of a released artifact. =A0 In ou=
r
> case, the "nightly" deploy build would deploy a 1.0.0-SNAPSHOT version of
> the parents, but Nexus' daily cleanup would then wipe them out and all th=
e
> other snapshots that are deployed are then useless.
>
>
>> I also have a concern about revision 1343766, which is also included
>> in this build. The version numbers of the current parent poms have
>> been moved to 1.0.1-SNAPSHOT, when they should be 1.0.0-SNAPSHOT. This
>> is a bit confusing, since they were 1.0.0-SNAPSHOT before the release.
>> However, our release policy
>> (http://aries.apache.org/development/releasingaries.html) says:
>
> No, you CANNOT have snapshots for a released version. =A0This is a Maven/=
Nexus
> thing.
>
>
>> "take the default for the first two questions, and set the new
>> development version to be the same as the one you are releasing! This
>> is because you don't know whether the next version released from the
>> trunk will have a major, minor or micro version number change - you
>> won't know until those changes are made! - so leave it for the person
>> making those changes to make the decision and move to module-new
>> version-SNAPSHOT."
>
> OK. =A0This needs to change. =A0This won't work as Nexus won't allow thos=
e
> snapshots to be at all usable or downloadable.
>
> Dan
>
>
>
>> Normally the pre-release version wouldn't have been 1.0.0-SNAPSHOT, so
>> that's partly my fault - when I did the pre-release work in the
>> branch, I changed the versions to 1.0.0 ones, since otherwise not much
>> would have been done in the branch!
>>
>> Could we please revert revision 1343766 to align with our release
>> policy and fix the build breaks?
>>
>> Holly
>>
>>
>>
>>
>> On Tue, May 29, 2012 at 5:46 PM, Apache Jenkins Server
>>
>> <jenkins@builds.apache.org> wrote:
>> > See <https://builds.apache.org/job/Aries/changes>
> --
> Daniel Kulp
> dkulp@apache.org - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com
>