As I understand it using -fae just says keep going if a failure occurs, it doesn't change the way maven works.
I ran with MFN clean install 4-5 times and other than the application tests everything worked. I'll try with mvn install tomorrow and let you know though. Alasdair Nottingham On 15 Sep 2010, at 20:04, Joe Bohn <[email protected]> wrote: > > Thanks for the input. > > I think building with -fn or -fae is somewhat of a different scenario and > masks the problem. If -fn or -fae are necessary then we should update the > wiki to indicate this. > > In my case I was trying to run with just mvn install (per our directions on > the wiki and what I think Hudson is doing). When a failure is encountered I > run mvn install again on the top level pom (the definition of insanity - > doing the same thing and expecting different results :-) ). This process > gets you into a potentially never ending cycle of failures as tests that > passed on the earlier attempts fail on subsequent attempts. > > For example, here are some real life results: > - mvn clean from root > - remove aries artifacts from maven local repo to ensure a clean starting > point (rm -rf ./m2/repository/org/apache/aries ) > - mvn install from root > - failures in application tests - IsolatedRuntimeTest, UpdateAppTest, > OBRResolverTest, and OBRResolverAdvancedTest > - mvn install from root > - failures in application tests - IsolatedRuntimeTest, OBRResolverTest and > OBRResolverAdvancedTest > - mvn install from root > - failures in blueprint tests - BlueprintContainer2Test and > QuiesceBlueprintTest (NOTE: didn't even get to application this time) > - mvn install from root > - failure in blueprint tests - QuiesceBlueprintTest > - mvn install from root > - failure in transaction tests - InvalidTranAttributeTest > - mvn install from root > - failure in blueprint tests - BlueprintAnnotationTest > - mvn install from root > - failure in blueprint test - QuiesceBlueprintTest > - on and on it goes ... where it stops ... nobody knows :-) > > I honestly don't know how the Hudson builds are working. It seems that the > best anyone on this thread has reported thus far is 50% success (and I'm not > sure if that was for a successful top level build as I was attempting and > Hudson appears to accomplish most of the time or if it was rebuilding just a > failing module individually). > > Joe > > > On 9/15/10 7:25 PM, Alasdair Nottingham wrote: >> So I've just run the build many times with the following: >> >> export MAVEN_OPTS=-Xmx512m >> mvn -fae clean install >> >> and the only failures I get are in the Aries Application integration >> tests component, I haven't looked at details. I'm running on a mac >> with java 6. >> >> Alasdair >> >> On 15 September 2010 09:42, Emily Jiang<[email protected]> wrote: >>> For me, two areas are constantly failing: blueprint itests: >>> quiesceBlueprintTests particularly failed very often followed by some of >>> application itests. >>> >>> Many thanks and kindest regards, >>> Emily >>> =========================== >>> Emily Jiang >>> WebSphere ESB Foundation Technologies >>> >>> MP 211, DE3A25, Winchester, Hampshire, England, SO21 2JN >>> Phone: +44 (0)1962 816278 Internal: 246278 >>> >>> Email: [email protected] >>> Lotus Notes: Emily Jiang/UK/i...@ibmgb >>> >>> >>> >>> >>> From: Mark Nuttall<[email protected]> >>> To: [email protected] >>> Date: 15/09/2010 17:20 >>> Subject: Re: building Apache Aries trunk from the top level pom >>> >>> >>> >>> I too find the application itests particularly flaky on a local mvn >>> command >>> line. I spent most of today trying to debug the sometimes-failing tests: I >>> couldn't get any to fail under a debugger, and couldn't work out from the >>> trace why any had failed otherwise :( >>> >>> Emily, Chris and I are going to be making changes to the application >>> provisioning and runtime areas for a while yet. I'm sorry if we've >>> introduced further problems in this area. I do think it's timing related >>> based on today's investigations. >>> >>> Mark >>> >>> On 15 September 2010 17:03, Valentin Mahrwald >>> <[email protected]>wrote: >>> >>>> I just checked and had a 50% success rate :) >>>> >>>> I have found some of the new tests in the application itest project are >>>> flaky (maybe the timeouts are not big enough). But the rest seems to >>> work >>>> for me. >>>> >>>> Valentin >>>> >>>> >>>> On 15 Sep 2010, at 10:28, Joe Bohn wrote: >>>> >>>>> >>>>> I seem to be having lots of problems building Apache Aries trunk from >>> the >>>> top level pom because of test errors. And, the more tests we add the >>> worse >>>> the process becomes. For me it is virtually impossible to build. Once >>> in a >>>> while I'll get lucky and things will actually work. However, most of the >>>> time it seems there are test failures somewhere along the way. The >>> failure >>>> is often a timeout waiting for a service. However, there are a large >>> number >>>> of other (strange) failures such as InvocationTargetExceptions, invalid >>>> state, NPEs, etc... that are becoming more common. >>>>> >>>>> When attempting to run a build from the top level a test that passes >>> on >>>> one attempt will fail on the next and the one that failed on the last >>> run >>>> will pass on the next (if the build even gets that far). All in all, it >>> is >>>> pretty much impossible to build from the top level. >>>>> >>>>> The only success that I have in building all of Apache Aries is to >>> build >>>> each module individually in the order specified in the top level pom >>> (which >>>> I think is now correct). As I hit failures I rebuild just that module >>> until >>>> successful and then I move on to the next module. >>>>> >>>>> So this raises 2 questions: >>>>> 1) Am I the only one seeing these types of problems? If it is just me >>>> then I guess I just need to figure out what is wrong with my >>> environment. >>>>> >>>>> 2) If it is more wide spread then it seems to me that we might have >>>> issues that we need to address. Certainly we are dealing with a dynamic >>>> system with loose coupling and there are very likely timing scenarios >>> that >>>> will arise occasionally. However, the frequency and variety of failures >>> I'm >>>> seeing makes me wonder if we have larger timing or synchronization >>> issues >>>> that have not yet been addressed. Do you agree? If so, then we need to >>>> come up with some way to isolate and resolve these issues. >>>>> >>>>> Joe >>>> >>>> >>> >>> >>> >>> >>> >>> >>> >>> Unless stated otherwise above: >>> IBM United Kingdom Limited - Registered in England and Wales with number >>> 741598. >>> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU >>> >>> >>> >>> >>> >>> >> >> >> > > > -- > Joe
