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

Reply via email to