I am looking at the application itest failures now and try to fix it.
Many thanks and kindest regards, Emily =========================== Emily Jiang From: Joe Bohn <[email protected]> To: [email protected] Date: 16/09/2010 13:03 Subject: Re: building Apache Aries trunk from the top level pom That's my understanding as well regarding -fae. It isn't that maven does anything different as it builds - it's just that using -fae or -fn causes the build to continue even when a failure is encountered. In the scenario I spelled out below (without using -fae or -fn) the failure causes the build to terminate immediately. You only get a complete image of all modules when everything succeeds in a single run (which practically never happens for me but seems to regularly happen on Hudson). Joe On 9/16/10 12:51 AM, Alasdair Nottingham wrote: > 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 > -- 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
