Failed to build Address Hierarchy module

Hi devs :slight_smile:
I’m currently working on this(Use Daemon to authenticate task) issue but I have failed to build a freshly cloned Address Hierarchy module . It fails with some tests failures without any code modification of commit :frowning:
Full error log is here
cc. @dkayiwa etc…
Please look into this, tell me why the build fails :slight_smile:

@mksd have glanced at this :slight_smile:

I can’t reproduce this though. Also clearly both Travis CI and the (OpenMRS) CI did pass on this, obviously.

Thanks for looking into this. But I still wonder what the problem could be. Any work arounds advise on troubleshooting this?

I have also tried to make sure my local master is equal to remote I just ran

git fetch upstream
git reset --hard upstream/master

But this still fails out on tests :frowning:

Would you have got access by any chance to another system to try this out? I know it’s a weird request, but there’s been issues with interfering tests with Spring Testing in AH at some point. Long story short it could happen that the problem you experience is very specific to the order in which tests are being fired by Maven, (and this is environment dependent).

I hope that’s not the problem, but just to rule this out you know…

Ugh if it’s the problem with the tests running in a different order… I think I ran into something similar than this in the REST web services module yesterday.

Another way to test that would be to try to run a mvn build but restricting the tests to the tests that are failing (I think you do that by adding something like -Dtests=“testname”, but I don’t remember 100%). If it still fails in that case, it doesn’t necessarily mean that it isn’t an order problem (because the problem might be that some other test needs to run first), but if they pass it means the order likely is the problem.

I wonder if there’s a way to control the order that maven tests run in? I know this would be bad practice, but if we don’t get around to figuring out why order matters, it would be better than nothing.

Taker care, Mark

To run a single test (example with AddressHierarchyServiceTest):

mvn test -Dtest=
AddressHierarchyServiceTest -pl api/

I had looked into that when I started bumping onto such issues and the short answer was definitely no. This randomness is kind of built-in to precisely enforce the independence of unit tests.

I suspect that this only occurs with Spring Testing, and there might be limited support in the framework for ensuring that context-sensitive tests are totally independent from each other. I definitely came across threads on SO where people faced such problems (and we did face them in AH as well). Not straightforward and time consuming :-1:

Yeah, I figured that was the case re: controlling the order of tests because I know I must have looked into it before… was hoping maybe that ability had been added since I last checked, or someone had a solution to do it I hadn’t though of… :slight_smile:

Take care, Mark

Thanks for precisely looking into this and getting concerned @mogoodrich but running a single maven test on the failing class fails with this log :slight_smile:

I have currently failed accessing another machine today :frowning:
But will try out tomorrow :slight_smile:

A Dockerised shell with Maven installed should do the trick though. That’s good opportunity to play around with Docker.

Thanks for the idea, but any resources about " Dockerised shell with Maven" sounds new to me :smile:

@samuel34 what does this return? mvn -v

$ mvn -v
Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T08:41:47-08:00)
Maven home: C:\Program Files\apache-maven-3.3.9
Java version: 1.8.0_121, vendor: Oracle Corporation
Java home: C:\Program Files\Java\jdk1.8.0_121\jre
Default locale: en_US, platform encoding: Cp1252
OS name: “windows 10”, version: “10.0”, arch: “amd64”, family: “dos”

cc: @dkayiwa

@samuel34 does it make any difference if you upgrade to the latest Java 1.8.x?

Ooohh am gonna upgrade to the latest version never know it may be the root cause :roll_eyes: