Hi Dmitry,
Found it:
I just checked out that branch and it builds fine locally on a win7 system with jdk 7. However, I have taken a dive into the exception stack trace and the NPEs during the schema validation are caused here:
at com.sun.org.apache.xerces.internal.util.DefaultErrorHandler.<init>(DefaultErrorHandler.java:54)
Which is this:
public DefaultErrorHandler() {
this(new PrintWriter(System.err));
} // <init>()
So, System err is null! There is only one spot in the codebase where System.err is modified: SimpleLoggerTest. Coincidently, this test is executed *last* during my local build. However, on Hudson it is not, thus causing System.err to be null for the remainder of the test execution. Ouch! The test has very strange semantics. I thought about simply retaining the original System.err / .out to set it back after the tests, but that’s not an option as this could still break parallel test execution. So I suppose that test needs to be re-written.
Regards,
Olaf
From: gemini-dev-bounces@xxxxxxxxxxx [mailto:gemini-dev-bounces@xxxxxxxxxxx] On Behalf Of Dmitry Sklyut
Sent: Freitag, 25. Oktober 2013 03:10
To: Gemini and sub-projects developer discussions
Subject: [gemini-dev] Blueprint builds
Hi All,
I pushed a set of changes to new branch "build". Basic cleanup of the pom and upgrade to bundlor. It runs perfectly fine on my local machine. Fails miserably on hudson[1]. It fails in places that make no sense to me. One example is reflection code, i.e. setting a property on a bean. Second is reading an xml file of classpath (class.getResource).
Has anyone experienced issues with shared hudson instance? I tried almost all of the jdks and maven configs possible.
Just for sanity check, anyone who is interested - please pull down the code and try to do a local build. I would like to make sure that these issues are isolated to eclipse hudson vs. something on my box.
I looked at other gemini jobs that use maven and I see nothing in configuration that would make those jobs run and blueprint fail.