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 >>>>>>>> >>>>>>>> >> > >
