aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Guillaume Nodet <>
Subject Re: Build stability, parent changes, and build #1469
Date Tue, 29 May 2012 19:26:35 GMT
I've fixed (hopefully) the concurrency issue.

On Tue, May 29, 2012 at 9:09 PM, Daniel Kulp <> wrote:
> On Tuesday, May 29, 2012 07:57:05 PM Holly Cummins wrote:
>> I noticed we've regressed the builds again. This is a shame, since
>> we'd managed to get the builds down to just two failures from the
>> fifty we had last week and the thirteen we had on Monday. I was really
>> hoping we'd get the builds clean so that I could resume 1.0.0 release
>> work. We were doing well, since the remaining failures have a clear
>> cause (ARIES-832) identified. The reason ARIES-832 causes breaks is
>> that it was delivered to a broken build, and the tests it 're-broke'
>> were already broken, so the 'new break' wasn't noticed. The fact that
>> we introduced breaks by delivering to a broken build is a good
>> argument in favour of Emily's suggestion that we should avoid
>> delivering to a broken build.
>> Unfortunately, we now have fourteen test failures which will need to
>> be fixed before 1.0.0 work can progress.
> Except the tests actually PASS on my machine with the changes.   That
> certainly makes it difficult to figure out what's causing it.   Likely
> something more timing related, but I'm not really sure yet.
>> 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
>> ( 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.     Without the change, you cannot build
> things like Karaf/trunk (which uses those snapshots right now) without first
> building Aries locally.   More in a sec.....
>> Since our
>> build instructions
>> ( state that
>> the way to build Aries is to build the parent first, I'm not sure
>> being able to build without building parent first is urgent enough
>> that it was worth destabilising the build for. I know we've discussed
>> being able to build without building the parent first before
>> (
>>, and I can see that building without
>> building parent first is nice. Maybe this is an issue we should come back
>> to once the build is
>> stabilised.
> This is only partially for this reason.   It's mostly to get the deployed
> snapshots to actually be usable for other projects to continue testing them.
> Nexus does NOT allow a snapshot version of a released artifact.   In our
> 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 the
> 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
>> ( says:
> No, you CANNOT have snapshots for a released version.  This 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.  This needs to change.  This won't work as Nexus won't allow those
> 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
>> <> wrote:
>> > See <>
> --
> Daniel Kulp
> -
> Talend Community Coder -

Guillaume Nodet
FuseSource, Integration everywhere

View raw message