aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Kulp <>
Subject Re: Build stability, parent changes, and build #1469
Date Tue, 29 May 2012 19:09:36 GMT
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 

> "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.  


> 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 -

View raw message