I've fixed (hopefully) the concurrency issue. On Tue, May 29, 2012 at 9:09 PM, Daniel Kulp <[email protected]> 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 >> (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. 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 >> (http://aries.apache.org/development/buildingaries.html) 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 >> (http://mail-archives.apache.org/mod_mbox/aries-dev/201111.mbox/%3C1129562 >> [email protected]%3E), 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 >> (http://aries.apache.org/development/releasingaries.html) 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 >> >> <[email protected]> wrote: >> > See <https://builds.apache.org/job/Aries/changes> > -- > Daniel Kulp > [email protected] - http://dankulp.com/blog > Talend Community Coder - http://coders.talend.com >
-- ------------------------ Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ FuseSource, Integration everywhere http://fusesource.com
