You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@uima.apache.org by Marshall Schor <ms...@schor.com> on 2014/11/04 22:43:44 UTC

something strange with Jenkins builds, test case failures

Hi,

I was watching the console log for UIMA-SDK #586, and noticed it said along the
way some failure indications, for instance:

testCAStoString(org.apache.uima.util.CasToInlineXmlTest)  Time elapsed: 0.027
sec  <<< FAILURE!

So, I was quite surprised when the build finished and sent email to this list
saying everything was successful.

Going to Jenkins test report for build # 586 here:
https://builds.apache.org/job/UIMA-SDK/org.apache.uima$uimaj-core/586/testReport/ says
there are no errors.

But looking at the console output
https://builds.apache.org/view/All/job/UIMA-SDK/586/console definitely shows
errors. 

(The errors seem to be due to different XML formatters; one writing <xxx  ....
/> and the other <xxx .... ></xxx>. Richard pointed me to a utility to get
around this, and I can add that, so these won't fail.)

But more importantly, does anyone have any idea why one part of Jenkins (the
console log) is reporting failures, and the other part (test summary) is saying
there are no failures?

-M

Re: something strange with Jenkins builds, test case failures

Posted by Richard Eckart de Castilho <re...@apache.org>.
Good question. The failure are recorded in the surefire XML reports, e.g. in

https://builds.apache.org/job/UIMA-SDK/ws/trunk/uimaj-core/target/surefire-reports/TEST-org.apache.uima.util.CasToInlineXmlTest.xml

I don't see anything that looks like it would cause failures to be ignored.

Maybe a bug?

Cheers,

-- Richard

On 04.11.2014, at 22:43, Marshall Schor <ms...@schor.com> wrote:

> Hi,
> 
> I was watching the console log for UIMA-SDK #586, and noticed it said along the
> way some failure indications, for instance:
> 
> testCAStoString(org.apache.uima.util.CasToInlineXmlTest)  Time elapsed: 0.027
> sec  <<< FAILURE!
> 
> So, I was quite surprised when the build finished and sent email to this list
> saying everything was successful.
> 
> Going to Jenkins test report for build # 586 here:
> https://builds.apache.org/job/UIMA-SDK/org.apache.uima$uimaj-core/586/testReport/ says
> there are no errors.
> 
> But looking at the console output
> https://builds.apache.org/view/All/job/UIMA-SDK/586/console definitely shows
> errors. 
> 
> (The errors seem to be due to different XML formatters; one writing <xxx  ....
> /> and the other <xxx .... ></xxx>. Richard pointed me to a utility to get
> around this, and I can add that, so these won't fail.)
> 
> But more importantly, does anyone have any idea why one part of Jenkins (the
> console log) is reporting failures, and the other part (test summary) is saying
> there are no failures?
> 
> -M


Re: something strange with Jenkins builds, test case failures

Posted by Richard Eckart de Castilho <re...@apache.org>.
I think it is rather a cosmetic problem that some tests fail with Cobertura,
as long as the surefire tests run ok in the "test" phase.

-- Richard

On 05.11.2014, at 21:33, Marshall Schor <ms...@schor.com> wrote:

> I wasn't able to get any help from the documentation for the Cobertura maven
> plugin.  It confirms it
>  - runs in its own custom maven lifecycle
>  - runs the "test" goal before it runs
> 
> I'm stuck at this point, I think.
> 
> -Marshall
> 
> On 11/5/2014 3:12 PM, Marshall Schor wrote:
>> Maven 3.2.1 fails.  Switched to 3.0.5.
>> 
>> Now, watching the findbugs run on the Jenkins console, it appears I missed the
>> fact that findbugs ran OK.  It was the next additional step, Cobertura, that
>> caused the compile and test (in some unusual environment) to re-run (and fail). 
>> I can reproduce this on my laptop :-)
>> 
>> I'll look at the Cobertura configuration...
>> 
>> -Marshall


Re: something strange with Jenkins builds, test case failures

Posted by Marshall Schor <ms...@schor.com>.
I wasn't able to get any help from the documentation for the Cobertura maven
plugin.  It confirms it
  - runs in its own custom maven lifecycle
  - runs the "test" goal before it runs

I'm stuck at this point, I think.

-Marshall

On 11/5/2014 3:12 PM, Marshall Schor wrote:
> Maven 3.2.1 fails.  Switched to 3.0.5.
>
> Now, watching the findbugs run on the Jenkins console, it appears I missed the
> fact that findbugs ran OK.  It was the next additional step, Cobertura, that
> caused the compile and test (in some unusual environment) to re-run (and fail). 
> I can reproduce this on my laptop :-)
>
> I'll look at the Cobertura configuration...
>
> -Marshall
> On 11/5/2014 2:36 PM, Marshall Schor wrote:
>> oops again.  Maven 3 latest runs maven 3.0.4, certainly not the lastest.  Trying
>> 3.2.1 (the latest listed).
>>
>> -Marshall
>> On 11/5/2014 2:32 PM, Marshall Schor wrote:
>>> oops, setting Maven to "latest", means latest of maven 2.
>>>
>>> There's another setting Maven 3 latest - trying that...
>>>
>>> -Marshall
>>> On 11/5/2014 2:21 PM, Marshall Schor wrote:
>>>> Running locally on my laptop (Windows) I observe:
>>>>
>>>> 1) mvn package -Pfindbugs  - runs with findbugs, both 3.0.0 (newer version) and
>>>> 2.5.4 (version being used), but findbugs doesn't print any indication like it
>>>> does on Jenkins that it's recursively rebuilding and re-running tests.
>>>>
>>>> I saw that my mvn version is 3.0.5, while the Jenkins was running 3.0.3.  So I
>>>> downgraded my laptop mvn version to 3.0.3 - the mvn build still runs fine.
>>>>
>>>>   - this means I can't reproduce this on my laptop.  It's likely that there's
>>>> some interaction with Jenkins and Maven which is causing this.
>>>>
>>>> 2) Just incidentally, I noticed that findbugs fails when running with Oracle
>>>> Java 8 (1.8.0_25-b18)
>>>>
>>>> message: [java]   Unable to get XClass for java/lang/StringBuffer
>>>> [java]     java.lang.ArrayIndexOutOfBoundsException: 26721
>>>> [java]       At org.objectweb.asm.ClassReader.readClass(Unknown Source) etc.
>>>>
>>>> it works OK with IBM Java 8 (build pwa6480ea-20130422_01)
>>>>
>>>> ----------
>>>> I've restored the build to Ubuntu || Windows, and changed the maven level to
>>>> "latest" (was 3.0.3).
>>>>
>>>> I'll probably close the issues as Not a problem, since the errors appear to be
>>>> specific for findbugs running in the Jenkins environment.
>>>>
>>>> -Marshall
>>>>
>>>> On 11/5/2014 10:57 AM, Marshall Schor wrote:
>>>>> Here's what's happening; it happens on both Windows1 and Ubuntu recent builds.
>>>>>
>>>>>
>>>>> The uimaj-core (where the "failing" test are) is built normally, no errors
>>>>>
>>>>>    - the Java is OK (
>>>>>        Oracle 1.7.0 Java HotSpot(TM) 64-Bit Server VM 21.0-b17 on Windows 1 and
>>>>>        Oracle 1.7.0_25 Java HotSpot(TM) Server VM 23.25-b01 on Ubuntu)
>>>>>
>>>>> However, the build on Jenkins includes a flag that causes Jenkins to run the
>>>>> "Findbugs" maven plugin.
>>>>>
>>>>> Findbugs maven plugin running seems unusual.  It causes a recursive build of the
>>>>> module, which not only recompiles everything, but re-runs the tests as well.  It
>>>>> is only this second running of the tests that fail.  It's likely that findbugs
>>>>> configuration is somehow specifying an older version of Xalan that ends up not
>>>>> supporting XML 1.1.
>>>>>
>>>>> Investigating further to see if we can configure Findbugs to not re-do the
>>>>> compilation and rerunning, and/or to fix its version of Xalan.
>>>>>
>>>>> -Marshall
>>>>>
>>>>>
>>>>> On 11/5/2014 10:38 AM, Marshall Schor wrote:
>>>>>> So, try # 1 was assigned "Windows2" - a different Windows machine than used
>>>>>> before (in build 586).  That build
>>>>>> didn't even get started - while Jenkins was parsing the maven poms, it threw a
>>>>>> fatal "out of permgen space". 
>>>>>> It sounds like the Java level installed on that machine has some configuration
>>>>>> issues.
>>>>>>
>>>>>> I restarted it, and it is assigned now to Windows1...
>>>>>>
>>>>>> -Marshall
>>>>>> On 11/5/2014 10:25 AM, Marshall Schor wrote:
>>>>>>> I added some debug output to record the JVM name and the specified name of the
>>>>>>> TransformerFactory (if any).
>>>>>>>
>>>>>>> I reran on Jenkins, and Jenkins picked the Ubuntu slave (failure was on
>>>>>>> Windows1) and I watched the console - no error reported on the xml tests.
>>>>>>>
>>>>>>> I've temporarily restricted the build for UIMA-SDK to "Windows" to see if I can
>>>>>>> reproduce this failure.
>>>>>>>
>>>>>>> -Marshall
>>>>>>>
>>>>>>> On 11/4/2014 4:43 PM, Marshall Schor wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> I was watching the console log for UIMA-SDK #586, and noticed it said along the
>>>>>>>> way some failure indications, for instance:
>>>>>>>>
>>>>>>>> testCAStoString(org.apache.uima.util.CasToInlineXmlTest)  Time elapsed: 0.027
>>>>>>>> sec  <<< FAILURE!
>>>>>>>>
>>>>>>>> So, I was quite surprised when the build finished and sent email to this list
>>>>>>>> saying everything was successful.
>>>>>>>>
>>>>>>>> Going to Jenkins test report for build # 586 here:
>>>>>>>> https://builds.apache.org/job/UIMA-SDK/org.apache.uima$uimaj-core/586/testReport/ says
>>>>>>>> there are no errors.
>>>>>>>>
>>>>>>>> But looking at the console output
>>>>>>>> https://builds.apache.org/view/All/job/UIMA-SDK/586/console definitely shows
>>>>>>>> errors. 
>>>>>>>>
>>>>>>>> (The errors seem to be due to different XML formatters; one writing <xxx  ....
>>>>>>>> /> and the other <xxx .... ></xxx>. Richard pointed me to a utility to get
>>>>>>>> around this, and I can add that, so these won't fail.)
>>>>>>>>
>>>>>>>> But more importantly, does anyone have any idea why one part of Jenkins (the
>>>>>>>> console log) is reporting failures, and the other part (test summary) is saying
>>>>>>>> there are no failures?
>>>>>>>>
>>>>>>>> -M
>>>>>>>>
>>>>>>>>
>>
>
>


Re: something strange with Jenkins builds, test case failures

Posted by Marshall Schor <ms...@schor.com>.
Maven 3.2.1 fails.  Switched to 3.0.5.

Now, watching the findbugs run on the Jenkins console, it appears I missed the
fact that findbugs ran OK.  It was the next additional step, Cobertura, that
caused the compile and test (in some unusual environment) to re-run (and fail). 
I can reproduce this on my laptop :-)

I'll look at the Cobertura configuration...

-Marshall
On 11/5/2014 2:36 PM, Marshall Schor wrote:
> oops again.  Maven 3 latest runs maven 3.0.4, certainly not the lastest.  Trying
> 3.2.1 (the latest listed).
>
> -Marshall
> On 11/5/2014 2:32 PM, Marshall Schor wrote:
>> oops, setting Maven to "latest", means latest of maven 2.
>>
>> There's another setting Maven 3 latest - trying that...
>>
>> -Marshall
>> On 11/5/2014 2:21 PM, Marshall Schor wrote:
>>> Running locally on my laptop (Windows) I observe:
>>>
>>> 1) mvn package -Pfindbugs  - runs with findbugs, both 3.0.0 (newer version) and
>>> 2.5.4 (version being used), but findbugs doesn't print any indication like it
>>> does on Jenkins that it's recursively rebuilding and re-running tests.
>>>
>>> I saw that my mvn version is 3.0.5, while the Jenkins was running 3.0.3.  So I
>>> downgraded my laptop mvn version to 3.0.3 - the mvn build still runs fine.
>>>
>>>   - this means I can't reproduce this on my laptop.  It's likely that there's
>>> some interaction with Jenkins and Maven which is causing this.
>>>
>>> 2) Just incidentally, I noticed that findbugs fails when running with Oracle
>>> Java 8 (1.8.0_25-b18)
>>>
>>> message: [java]   Unable to get XClass for java/lang/StringBuffer
>>> [java]     java.lang.ArrayIndexOutOfBoundsException: 26721
>>> [java]       At org.objectweb.asm.ClassReader.readClass(Unknown Source) etc.
>>>
>>> it works OK with IBM Java 8 (build pwa6480ea-20130422_01)
>>>
>>> ----------
>>> I've restored the build to Ubuntu || Windows, and changed the maven level to
>>> "latest" (was 3.0.3).
>>>
>>> I'll probably close the issues as Not a problem, since the errors appear to be
>>> specific for findbugs running in the Jenkins environment.
>>>
>>> -Marshall
>>>
>>> On 11/5/2014 10:57 AM, Marshall Schor wrote:
>>>> Here's what's happening; it happens on both Windows1 and Ubuntu recent builds.
>>>>
>>>>
>>>> The uimaj-core (where the "failing" test are) is built normally, no errors
>>>>
>>>>    - the Java is OK (
>>>>        Oracle 1.7.0 Java HotSpot(TM) 64-Bit Server VM 21.0-b17 on Windows 1 and
>>>>        Oracle 1.7.0_25 Java HotSpot(TM) Server VM 23.25-b01 on Ubuntu)
>>>>
>>>> However, the build on Jenkins includes a flag that causes Jenkins to run the
>>>> "Findbugs" maven plugin.
>>>>
>>>> Findbugs maven plugin running seems unusual.  It causes a recursive build of the
>>>> module, which not only recompiles everything, but re-runs the tests as well.  It
>>>> is only this second running of the tests that fail.  It's likely that findbugs
>>>> configuration is somehow specifying an older version of Xalan that ends up not
>>>> supporting XML 1.1.
>>>>
>>>> Investigating further to see if we can configure Findbugs to not re-do the
>>>> compilation and rerunning, and/or to fix its version of Xalan.
>>>>
>>>> -Marshall
>>>>
>>>>
>>>> On 11/5/2014 10:38 AM, Marshall Schor wrote:
>>>>> So, try # 1 was assigned "Windows2" - a different Windows machine than used
>>>>> before (in build 586).  That build
>>>>> didn't even get started - while Jenkins was parsing the maven poms, it threw a
>>>>> fatal "out of permgen space". 
>>>>> It sounds like the Java level installed on that machine has some configuration
>>>>> issues.
>>>>>
>>>>> I restarted it, and it is assigned now to Windows1...
>>>>>
>>>>> -Marshall
>>>>> On 11/5/2014 10:25 AM, Marshall Schor wrote:
>>>>>> I added some debug output to record the JVM name and the specified name of the
>>>>>> TransformerFactory (if any).
>>>>>>
>>>>>> I reran on Jenkins, and Jenkins picked the Ubuntu slave (failure was on
>>>>>> Windows1) and I watched the console - no error reported on the xml tests.
>>>>>>
>>>>>> I've temporarily restricted the build for UIMA-SDK to "Windows" to see if I can
>>>>>> reproduce this failure.
>>>>>>
>>>>>> -Marshall
>>>>>>
>>>>>> On 11/4/2014 4:43 PM, Marshall Schor wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> I was watching the console log for UIMA-SDK #586, and noticed it said along the
>>>>>>> way some failure indications, for instance:
>>>>>>>
>>>>>>> testCAStoString(org.apache.uima.util.CasToInlineXmlTest)  Time elapsed: 0.027
>>>>>>> sec  <<< FAILURE!
>>>>>>>
>>>>>>> So, I was quite surprised when the build finished and sent email to this list
>>>>>>> saying everything was successful.
>>>>>>>
>>>>>>> Going to Jenkins test report for build # 586 here:
>>>>>>> https://builds.apache.org/job/UIMA-SDK/org.apache.uima$uimaj-core/586/testReport/ says
>>>>>>> there are no errors.
>>>>>>>
>>>>>>> But looking at the console output
>>>>>>> https://builds.apache.org/view/All/job/UIMA-SDK/586/console definitely shows
>>>>>>> errors. 
>>>>>>>
>>>>>>> (The errors seem to be due to different XML formatters; one writing <xxx  ....
>>>>>>> /> and the other <xxx .... ></xxx>. Richard pointed me to a utility to get
>>>>>>> around this, and I can add that, so these won't fail.)
>>>>>>>
>>>>>>> But more importantly, does anyone have any idea why one part of Jenkins (the
>>>>>>> console log) is reporting failures, and the other part (test summary) is saying
>>>>>>> there are no failures?
>>>>>>>
>>>>>>> -M
>>>>>>>
>>>>>>>
>>
>
>


Re: something strange with Jenkins builds, test case failures

Posted by Marshall Schor <ms...@schor.com>.
oops again.  Maven 3 latest runs maven 3.0.4, certainly not the lastest.  Trying
3.2.1 (the latest listed).

-Marshall
On 11/5/2014 2:32 PM, Marshall Schor wrote:
> oops, setting Maven to "latest", means latest of maven 2.
>
> There's another setting Maven 3 latest - trying that...
>
> -Marshall
> On 11/5/2014 2:21 PM, Marshall Schor wrote:
>> Running locally on my laptop (Windows) I observe:
>>
>> 1) mvn package -Pfindbugs  - runs with findbugs, both 3.0.0 (newer version) and
>> 2.5.4 (version being used), but findbugs doesn't print any indication like it
>> does on Jenkins that it's recursively rebuilding and re-running tests.
>>
>> I saw that my mvn version is 3.0.5, while the Jenkins was running 3.0.3.  So I
>> downgraded my laptop mvn version to 3.0.3 - the mvn build still runs fine.
>>
>>   - this means I can't reproduce this on my laptop.  It's likely that there's
>> some interaction with Jenkins and Maven which is causing this.
>>
>> 2) Just incidentally, I noticed that findbugs fails when running with Oracle
>> Java 8 (1.8.0_25-b18)
>>
>> message: [java]   Unable to get XClass for java/lang/StringBuffer
>> [java]     java.lang.ArrayIndexOutOfBoundsException: 26721
>> [java]       At org.objectweb.asm.ClassReader.readClass(Unknown Source) etc.
>>
>> it works OK with IBM Java 8 (build pwa6480ea-20130422_01)
>>
>> ----------
>> I've restored the build to Ubuntu || Windows, and changed the maven level to
>> "latest" (was 3.0.3).
>>
>> I'll probably close the issues as Not a problem, since the errors appear to be
>> specific for findbugs running in the Jenkins environment.
>>
>> -Marshall
>>
>> On 11/5/2014 10:57 AM, Marshall Schor wrote:
>>> Here's what's happening; it happens on both Windows1 and Ubuntu recent builds.
>>>
>>>
>>> The uimaj-core (where the "failing" test are) is built normally, no errors
>>>
>>>    - the Java is OK (
>>>        Oracle 1.7.0 Java HotSpot(TM) 64-Bit Server VM 21.0-b17 on Windows 1 and
>>>        Oracle 1.7.0_25 Java HotSpot(TM) Server VM 23.25-b01 on Ubuntu)
>>>
>>> However, the build on Jenkins includes a flag that causes Jenkins to run the
>>> "Findbugs" maven plugin.
>>>
>>> Findbugs maven plugin running seems unusual.  It causes a recursive build of the
>>> module, which not only recompiles everything, but re-runs the tests as well.  It
>>> is only this second running of the tests that fail.  It's likely that findbugs
>>> configuration is somehow specifying an older version of Xalan that ends up not
>>> supporting XML 1.1.
>>>
>>> Investigating further to see if we can configure Findbugs to not re-do the
>>> compilation and rerunning, and/or to fix its version of Xalan.
>>>
>>> -Marshall
>>>
>>>
>>> On 11/5/2014 10:38 AM, Marshall Schor wrote:
>>>> So, try # 1 was assigned "Windows2" - a different Windows machine than used
>>>> before (in build 586).  That build
>>>> didn't even get started - while Jenkins was parsing the maven poms, it threw a
>>>> fatal "out of permgen space". 
>>>> It sounds like the Java level installed on that machine has some configuration
>>>> issues.
>>>>
>>>> I restarted it, and it is assigned now to Windows1...
>>>>
>>>> -Marshall
>>>> On 11/5/2014 10:25 AM, Marshall Schor wrote:
>>>>> I added some debug output to record the JVM name and the specified name of the
>>>>> TransformerFactory (if any).
>>>>>
>>>>> I reran on Jenkins, and Jenkins picked the Ubuntu slave (failure was on
>>>>> Windows1) and I watched the console - no error reported on the xml tests.
>>>>>
>>>>> I've temporarily restricted the build for UIMA-SDK to "Windows" to see if I can
>>>>> reproduce this failure.
>>>>>
>>>>> -Marshall
>>>>>
>>>>> On 11/4/2014 4:43 PM, Marshall Schor wrote:
>>>>>> Hi,
>>>>>>
>>>>>> I was watching the console log for UIMA-SDK #586, and noticed it said along the
>>>>>> way some failure indications, for instance:
>>>>>>
>>>>>> testCAStoString(org.apache.uima.util.CasToInlineXmlTest)  Time elapsed: 0.027
>>>>>> sec  <<< FAILURE!
>>>>>>
>>>>>> So, I was quite surprised when the build finished and sent email to this list
>>>>>> saying everything was successful.
>>>>>>
>>>>>> Going to Jenkins test report for build # 586 here:
>>>>>> https://builds.apache.org/job/UIMA-SDK/org.apache.uima$uimaj-core/586/testReport/ says
>>>>>> there are no errors.
>>>>>>
>>>>>> But looking at the console output
>>>>>> https://builds.apache.org/view/All/job/UIMA-SDK/586/console definitely shows
>>>>>> errors. 
>>>>>>
>>>>>> (The errors seem to be due to different XML formatters; one writing <xxx  ....
>>>>>> /> and the other <xxx .... ></xxx>. Richard pointed me to a utility to get
>>>>>> around this, and I can add that, so these won't fail.)
>>>>>>
>>>>>> But more importantly, does anyone have any idea why one part of Jenkins (the
>>>>>> console log) is reporting failures, and the other part (test summary) is saying
>>>>>> there are no failures?
>>>>>>
>>>>>> -M
>>>>>>
>>>>>>
>>
>
>


Re: something strange with Jenkins builds, test case failures

Posted by Marshall Schor <ms...@schor.com>.
oops, setting Maven to "latest", means latest of maven 2.

There's another setting Maven 3 latest - trying that...

-Marshall
On 11/5/2014 2:21 PM, Marshall Schor wrote:
> Running locally on my laptop (Windows) I observe:
>
> 1) mvn package -Pfindbugs  - runs with findbugs, both 3.0.0 (newer version) and
> 2.5.4 (version being used), but findbugs doesn't print any indication like it
> does on Jenkins that it's recursively rebuilding and re-running tests.
>
> I saw that my mvn version is 3.0.5, while the Jenkins was running 3.0.3.  So I
> downgraded my laptop mvn version to 3.0.3 - the mvn build still runs fine.
>
>   - this means I can't reproduce this on my laptop.  It's likely that there's
> some interaction with Jenkins and Maven which is causing this.
>
> 2) Just incidentally, I noticed that findbugs fails when running with Oracle
> Java 8 (1.8.0_25-b18)
>
> message: [java]   Unable to get XClass for java/lang/StringBuffer
> [java]     java.lang.ArrayIndexOutOfBoundsException: 26721
> [java]       At org.objectweb.asm.ClassReader.readClass(Unknown Source) etc.
>
> it works OK with IBM Java 8 (build pwa6480ea-20130422_01)
>
> ----------
> I've restored the build to Ubuntu || Windows, and changed the maven level to
> "latest" (was 3.0.3).
>
> I'll probably close the issues as Not a problem, since the errors appear to be
> specific for findbugs running in the Jenkins environment.
>
> -Marshall
>
> On 11/5/2014 10:57 AM, Marshall Schor wrote:
>> Here's what's happening; it happens on both Windows1 and Ubuntu recent builds.
>>
>>
>> The uimaj-core (where the "failing" test are) is built normally, no errors
>>
>>    - the Java is OK (
>>        Oracle 1.7.0 Java HotSpot(TM) 64-Bit Server VM 21.0-b17 on Windows 1 and
>>        Oracle 1.7.0_25 Java HotSpot(TM) Server VM 23.25-b01 on Ubuntu)
>>
>> However, the build on Jenkins includes a flag that causes Jenkins to run the
>> "Findbugs" maven plugin.
>>
>> Findbugs maven plugin running seems unusual.  It causes a recursive build of the
>> module, which not only recompiles everything, but re-runs the tests as well.  It
>> is only this second running of the tests that fail.  It's likely that findbugs
>> configuration is somehow specifying an older version of Xalan that ends up not
>> supporting XML 1.1.
>>
>> Investigating further to see if we can configure Findbugs to not re-do the
>> compilation and rerunning, and/or to fix its version of Xalan.
>>
>> -Marshall
>>
>>
>> On 11/5/2014 10:38 AM, Marshall Schor wrote:
>>> So, try # 1 was assigned "Windows2" - a different Windows machine than used
>>> before (in build 586).  That build
>>> didn't even get started - while Jenkins was parsing the maven poms, it threw a
>>> fatal "out of permgen space". 
>>> It sounds like the Java level installed on that machine has some configuration
>>> issues.
>>>
>>> I restarted it, and it is assigned now to Windows1...
>>>
>>> -Marshall
>>> On 11/5/2014 10:25 AM, Marshall Schor wrote:
>>>> I added some debug output to record the JVM name and the specified name of the
>>>> TransformerFactory (if any).
>>>>
>>>> I reran on Jenkins, and Jenkins picked the Ubuntu slave (failure was on
>>>> Windows1) and I watched the console - no error reported on the xml tests.
>>>>
>>>> I've temporarily restricted the build for UIMA-SDK to "Windows" to see if I can
>>>> reproduce this failure.
>>>>
>>>> -Marshall
>>>>
>>>> On 11/4/2014 4:43 PM, Marshall Schor wrote:
>>>>> Hi,
>>>>>
>>>>> I was watching the console log for UIMA-SDK #586, and noticed it said along the
>>>>> way some failure indications, for instance:
>>>>>
>>>>> testCAStoString(org.apache.uima.util.CasToInlineXmlTest)  Time elapsed: 0.027
>>>>> sec  <<< FAILURE!
>>>>>
>>>>> So, I was quite surprised when the build finished and sent email to this list
>>>>> saying everything was successful.
>>>>>
>>>>> Going to Jenkins test report for build # 586 here:
>>>>> https://builds.apache.org/job/UIMA-SDK/org.apache.uima$uimaj-core/586/testReport/ says
>>>>> there are no errors.
>>>>>
>>>>> But looking at the console output
>>>>> https://builds.apache.org/view/All/job/UIMA-SDK/586/console definitely shows
>>>>> errors. 
>>>>>
>>>>> (The errors seem to be due to different XML formatters; one writing <xxx  ....
>>>>> /> and the other <xxx .... ></xxx>. Richard pointed me to a utility to get
>>>>> around this, and I can add that, so these won't fail.)
>>>>>
>>>>> But more importantly, does anyone have any idea why one part of Jenkins (the
>>>>> console log) is reporting failures, and the other part (test summary) is saying
>>>>> there are no failures?
>>>>>
>>>>> -M
>>>>>
>>>>>
>>
>
>


Re: something strange with Jenkins builds, test case failures

Posted by Marshall Schor <ms...@schor.com>.
Running locally on my laptop (Windows) I observe:

1) mvn package -Pfindbugs  - runs with findbugs, both 3.0.0 (newer version) and
2.5.4 (version being used), but findbugs doesn't print any indication like it
does on Jenkins that it's recursively rebuilding and re-running tests.

I saw that my mvn version is 3.0.5, while the Jenkins was running 3.0.3.  So I
downgraded my laptop mvn version to 3.0.3 - the mvn build still runs fine.

  - this means I can't reproduce this on my laptop.  It's likely that there's
some interaction with Jenkins and Maven which is causing this.

2) Just incidentally, I noticed that findbugs fails when running with Oracle
Java 8 (1.8.0_25-b18)

message: [java]   Unable to get XClass for java/lang/StringBuffer
[java]     java.lang.ArrayIndexOutOfBoundsException: 26721
[java]       At org.objectweb.asm.ClassReader.readClass(Unknown Source) etc.

it works OK with IBM Java 8 (build pwa6480ea-20130422_01)

----------
I've restored the build to Ubuntu || Windows, and changed the maven level to
"latest" (was 3.0.3).

I'll probably close the issues as Not a problem, since the errors appear to be
specific for findbugs running in the Jenkins environment.

-Marshall

On 11/5/2014 10:57 AM, Marshall Schor wrote:
> Here's what's happening; it happens on both Windows1 and Ubuntu recent builds.
>
>
> The uimaj-core (where the "failing" test are) is built normally, no errors
>
>    - the Java is OK (
>        Oracle 1.7.0 Java HotSpot(TM) 64-Bit Server VM 21.0-b17 on Windows 1 and
>        Oracle 1.7.0_25 Java HotSpot(TM) Server VM 23.25-b01 on Ubuntu)
>
> However, the build on Jenkins includes a flag that causes Jenkins to run the
> "Findbugs" maven plugin.
>
> Findbugs maven plugin running seems unusual.  It causes a recursive build of the
> module, which not only recompiles everything, but re-runs the tests as well.  It
> is only this second running of the tests that fail.  It's likely that findbugs
> configuration is somehow specifying an older version of Xalan that ends up not
> supporting XML 1.1.
>
> Investigating further to see if we can configure Findbugs to not re-do the
> compilation and rerunning, and/or to fix its version of Xalan.
>
> -Marshall
>
>
> On 11/5/2014 10:38 AM, Marshall Schor wrote:
>> So, try # 1 was assigned "Windows2" - a different Windows machine than used
>> before (in build 586).  That build
>> didn't even get started - while Jenkins was parsing the maven poms, it threw a
>> fatal "out of permgen space". 
>> It sounds like the Java level installed on that machine has some configuration
>> issues.
>>
>> I restarted it, and it is assigned now to Windows1...
>>
>> -Marshall
>> On 11/5/2014 10:25 AM, Marshall Schor wrote:
>>> I added some debug output to record the JVM name and the specified name of the
>>> TransformerFactory (if any).
>>>
>>> I reran on Jenkins, and Jenkins picked the Ubuntu slave (failure was on
>>> Windows1) and I watched the console - no error reported on the xml tests.
>>>
>>> I've temporarily restricted the build for UIMA-SDK to "Windows" to see if I can
>>> reproduce this failure.
>>>
>>> -Marshall
>>>
>>> On 11/4/2014 4:43 PM, Marshall Schor wrote:
>>>> Hi,
>>>>
>>>> I was watching the console log for UIMA-SDK #586, and noticed it said along the
>>>> way some failure indications, for instance:
>>>>
>>>> testCAStoString(org.apache.uima.util.CasToInlineXmlTest)  Time elapsed: 0.027
>>>> sec  <<< FAILURE!
>>>>
>>>> So, I was quite surprised when the build finished and sent email to this list
>>>> saying everything was successful.
>>>>
>>>> Going to Jenkins test report for build # 586 here:
>>>> https://builds.apache.org/job/UIMA-SDK/org.apache.uima$uimaj-core/586/testReport/ says
>>>> there are no errors.
>>>>
>>>> But looking at the console output
>>>> https://builds.apache.org/view/All/job/UIMA-SDK/586/console definitely shows
>>>> errors. 
>>>>
>>>> (The errors seem to be due to different XML formatters; one writing <xxx  ....
>>>> /> and the other <xxx .... ></xxx>. Richard pointed me to a utility to get
>>>> around this, and I can add that, so these won't fail.)
>>>>
>>>> But more importantly, does anyone have any idea why one part of Jenkins (the
>>>> console log) is reporting failures, and the other part (test summary) is saying
>>>> there are no failures?
>>>>
>>>> -M
>>>>
>>>>
>>
>
>


Re: something strange with Jenkins builds, test case failures

Posted by Marshall Schor <ms...@schor.com>.
Here's what's happening; it happens on both Windows1 and Ubuntu recent builds.


The uimaj-core (where the "failing" test are) is built normally, no errors

   - the Java is OK (
       Oracle 1.7.0 Java HotSpot(TM) 64-Bit Server VM 21.0-b17 on Windows 1 and
       Oracle 1.7.0_25 Java HotSpot(TM) Server VM 23.25-b01 on Ubuntu)

However, the build on Jenkins includes a flag that causes Jenkins to run the
"Findbugs" maven plugin.

Findbugs maven plugin running seems unusual.  It causes a recursive build of the
module, which not only recompiles everything, but re-runs the tests as well.  It
is only this second running of the tests that fail.  It's likely that findbugs
configuration is somehow specifying an older version of Xalan that ends up not
supporting XML 1.1.

Investigating further to see if we can configure Findbugs to not re-do the
compilation and rerunning, and/or to fix its version of Xalan.

-Marshall


On 11/5/2014 10:38 AM, Marshall Schor wrote:
> So, try # 1 was assigned "Windows2" - a different Windows machine than used
> before (in build 586).  That build
> didn't even get started - while Jenkins was parsing the maven poms, it threw a
> fatal "out of permgen space". 
> It sounds like the Java level installed on that machine has some configuration
> issues.
>
> I restarted it, and it is assigned now to Windows1...
>
> -Marshall
> On 11/5/2014 10:25 AM, Marshall Schor wrote:
>> I added some debug output to record the JVM name and the specified name of the
>> TransformerFactory (if any).
>>
>> I reran on Jenkins, and Jenkins picked the Ubuntu slave (failure was on
>> Windows1) and I watched the console - no error reported on the xml tests.
>>
>> I've temporarily restricted the build for UIMA-SDK to "Windows" to see if I can
>> reproduce this failure.
>>
>> -Marshall
>>
>> On 11/4/2014 4:43 PM, Marshall Schor wrote:
>>> Hi,
>>>
>>> I was watching the console log for UIMA-SDK #586, and noticed it said along the
>>> way some failure indications, for instance:
>>>
>>> testCAStoString(org.apache.uima.util.CasToInlineXmlTest)  Time elapsed: 0.027
>>> sec  <<< FAILURE!
>>>
>>> So, I was quite surprised when the build finished and sent email to this list
>>> saying everything was successful.
>>>
>>> Going to Jenkins test report for build # 586 here:
>>> https://builds.apache.org/job/UIMA-SDK/org.apache.uima$uimaj-core/586/testReport/ says
>>> there are no errors.
>>>
>>> But looking at the console output
>>> https://builds.apache.org/view/All/job/UIMA-SDK/586/console definitely shows
>>> errors. 
>>>
>>> (The errors seem to be due to different XML formatters; one writing <xxx  ....
>>> /> and the other <xxx .... ></xxx>. Richard pointed me to a utility to get
>>> around this, and I can add that, so these won't fail.)
>>>
>>> But more importantly, does anyone have any idea why one part of Jenkins (the
>>> console log) is reporting failures, and the other part (test summary) is saying
>>> there are no failures?
>>>
>>> -M
>>>
>>>
>>
>
>


Re: something strange with Jenkins builds, test case failures

Posted by Marshall Schor <ms...@schor.com>.
So, try # 1 was assigned "Windows2" - a different Windows machine than used
before (in build 586).  That build
didn't even get started - while Jenkins was parsing the maven poms, it threw a
fatal "out of permgen space". 
It sounds like the Java level installed on that machine has some configuration
issues.

I restarted it, and it is assigned now to Windows1...

-Marshall
On 11/5/2014 10:25 AM, Marshall Schor wrote:
> I added some debug output to record the JVM name and the specified name of the
> TransformerFactory (if any).
>
> I reran on Jenkins, and Jenkins picked the Ubuntu slave (failure was on
> Windows1) and I watched the console - no error reported on the xml tests.
>
> I've temporarily restricted the build for UIMA-SDK to "Windows" to see if I can
> reproduce this failure.
>
> -Marshall
>
> On 11/4/2014 4:43 PM, Marshall Schor wrote:
>> Hi,
>>
>> I was watching the console log for UIMA-SDK #586, and noticed it said along the
>> way some failure indications, for instance:
>>
>> testCAStoString(org.apache.uima.util.CasToInlineXmlTest)  Time elapsed: 0.027
>> sec  <<< FAILURE!
>>
>> So, I was quite surprised when the build finished and sent email to this list
>> saying everything was successful.
>>
>> Going to Jenkins test report for build # 586 here:
>> https://builds.apache.org/job/UIMA-SDK/org.apache.uima$uimaj-core/586/testReport/ says
>> there are no errors.
>>
>> But looking at the console output
>> https://builds.apache.org/view/All/job/UIMA-SDK/586/console definitely shows
>> errors. 
>>
>> (The errors seem to be due to different XML formatters; one writing <xxx  ....
>> /> and the other <xxx .... ></xxx>. Richard pointed me to a utility to get
>> around this, and I can add that, so these won't fail.)
>>
>> But more importantly, does anyone have any idea why one part of Jenkins (the
>> console log) is reporting failures, and the other part (test summary) is saying
>> there are no failures?
>>
>> -M
>>
>>
>
>


Re: something strange with Jenkins builds, test case failures

Posted by Marshall Schor <ms...@schor.com>.
I added some debug output to record the JVM name and the specified name of the
TransformerFactory (if any).

I reran on Jenkins, and Jenkins picked the Ubuntu slave (failure was on
Windows1) and I watched the console - no error reported on the xml tests.

I've temporarily restricted the build for UIMA-SDK to "Windows" to see if I can
reproduce this failure.

-Marshall

On 11/4/2014 4:43 PM, Marshall Schor wrote:
> Hi,
>
> I was watching the console log for UIMA-SDK #586, and noticed it said along the
> way some failure indications, for instance:
>
> testCAStoString(org.apache.uima.util.CasToInlineXmlTest)  Time elapsed: 0.027
> sec  <<< FAILURE!
>
> So, I was quite surprised when the build finished and sent email to this list
> saying everything was successful.
>
> Going to Jenkins test report for build # 586 here:
> https://builds.apache.org/job/UIMA-SDK/org.apache.uima$uimaj-core/586/testReport/ says
> there are no errors.
>
> But looking at the console output
> https://builds.apache.org/view/All/job/UIMA-SDK/586/console definitely shows
> errors. 
>
> (The errors seem to be due to different XML formatters; one writing <xxx  ....
> /> and the other <xxx .... ></xxx>. Richard pointed me to a utility to get
> around this, and I can add that, so these won't fail.)
>
> But more importantly, does anyone have any idea why one part of Jenkins (the
> console log) is reporting failures, and the other part (test summary) is saying
> there are no failures?
>
> -M
>
>