FWIW, it looks like the unit test in question is bad, in that it's sensitive to the clock time, so putting a Thread.sleep(100) in the middle of the test fixes it.
But looking at the code I realized that we're not doing things exactly right. Currently, when you unvoid a patient, it also unvoids any of their encounters and orders with the same voidedBy and dateVoided. But we're not looking for the same voidReason. Any reason we shouldn't be looking at that too? -Darius On Fri, Sep 9, 2011 at 8:27 PM, Darius Jazayeri <[email protected]> wrote: > So, it looks like the specific problem I was running into is that I was > using a workspace folder under one of the parallels-mapped network drives > (\\psf\...) and one of Eclipse/Maven/Java/WinXP didn't like that. So after > switching to c:\workspace, I was able to get the build to run. > > Of course then I hit a unit test failure, which happens on this windows VM, > but not on the up-to-date checkout I have on my regular OSX install... > > PatientDataUnvoidHandlerTest > org.openmrs.api.handler.PatientDataUnvoidHandlerTest > > handle_shouldNotUnvoidTheOrdersAndEncountersThatNeverGotVoidedWithThePatient(org.openmrs.api.handler.PatientDataUnvoidHandlerTest) > java.lang.AssertionError: > at org.junit.Assert.fail(Assert.java:91) > at org.junit.Assert.assertTrue(Assert.java:43) > at org.junit.Assert.assertTrue(Assert.java:54) > at > org.openmrs.api.handler.PatientDataUnvoidHandlerTest.handle_shouldNotUnvoidTheOrdersAndEncountersThatNeverGotVoidedWithThePatient(PatientDataUnvoidHandlerTest.java:134) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at > org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44) > at > org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) > at > org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41) > at > org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20) > at > org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28) > at > org.springframework.test.context.junit4.statements.RunBeforeTestMethodCallbacks.evaluate(RunBeforeTestMethodCallbacks.java:74) > at > org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31) > at > org.springframework.test.context.junit4.statements.RunAfterTestMethodCallbacks.evaluate(RunAfterTestMethodCallbacks.java:82) > at > org.springframework.test.context.junit4.statements.SpringRepeat.evaluate(SpringRepeat.java:72) > at > org.springframework.test.context.junit4.SpringJUnit4ClassRunner.runChild(SpringJUnit4ClassRunner.java:240) > at > org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50) > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191) > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184) > at > org.springframework.test.context.junit4.statements.RunBeforeTestClassCallbacks.evaluate(RunBeforeTestClassCallbacks.java:61) > at > org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31) > at > org.springframework.test.context.junit4.statements.RunAfterTestClassCallbacks.evaluate(RunAfterTestClassCallbacks.java:70) > at org.junit.runners.ParentRunner.run(ParentRunner.java:236) > at > org.springframework.test.context.junit4.SpringJUnit4ClassRunner.run(SpringJUnit4ClassRunner.java:180) > at > org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:50) > at > org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) > at > org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467) > at > org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683) > at > org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390) > at > org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197) > > -Darius > > On Fri, Sep 9, 2011 at 7:51 PM, Darius Jazayeri <[email protected]>wrote: > >> Oh, also, when I check out the code, I get the warning message in this >> screenshot. >> >> -Darius >> >> >> On Fri, Sep 9, 2011 at 7:42 PM, Darius Jazayeri <[email protected]>wrote: >> >>> Hi All, >>> >>> I've attempted to record a screencast about "how to install OpenMRS as a >>> core developer" several times now, and each time I run into a (different) >>> showstopper in the middle of my screencast. (This is not a good commentary >>> on our reliance on Eclipse as our recommended development platform, FWIW.) >>> >>> I've worked around a few of the issues (mysql not installing, Eclipse >>> using the JRE instead of the JDK), but now I'm running into a showstopper >>> I've never seen before, and I have no idea what's up. I'm running on a >>> Windows XP virtual machine through Parallels on OSX, and after installing >>> the relevant eclipse plugins and checking out the trunk code, I hit several >>> bugs. The plugins I've installed are: >>> * Maven Integration for Eclipse (1.0.0.20110607-2117) >>> * Subclipse (1.6.18) >>> * m2e connector for maven-scm-plugin (1.0.0.201107091852) >>> * Maven SCM handler for Subclipse (0.13.0.201107071330) >>> After installing those, the first time I tried to do a maven build, >>> Eclipse asked me to install these two plugins: (I have never seen this >>> behavior before, but the plugin versions I installed for this screencast are >>> newer than what I've used before...) >>> * m2e connector for build-helper-maven-plugin (0.13.0.20110622-1538) >>> * m2e connector for mavenarchiver pom properties (0.14.0.201108020602) >>> >>> 1. If I try to Run As -> Maven install on the root OpenMRS project, it >>> fails, with the message below. (This doesn't make sense because the version >>> numbers of those two dependencies are given in the dependencyManagement >>> section of the pom.xml of the parent project... >>> >>> [INFO] Scanning for projects... >>> [ERROR] The build could not read 1 project -> [Help 1] >>> [ERROR] >>> [ERROR] The project org.openmrs.web:openmrs-web:1.9.0-SNAPSHOT >>> (\\psf\Home\workspace\openmrs\web\pom.xml) has 2 errors >>> [ERROR] 'dependencies.dependency.version' for >>> postgresql:postgresql:jar is missing. @ line 89, column 19 >>> [ERROR] 'dependencies.dependency.version' for >>> net.sourceforge.jtds:jtds:jar is missing. @ line 93, column 19 >>> [ERROR] >>> [ERROR] To see the full stack trace of the errors, re-run Maven with the >>> -e switch. >>> [ERROR] Re-run Maven using the -X switch to enable full debug logging. >>> [ERROR] >>> [ERROR] For more information about the errors and possible solutions, >>> please read the following articles: >>> [ERROR] [Help 1] >>> http://cwiki.apache.org/confluence/display/MAVEN/ProjectBuildingException >>> >>> 2. When I open up the pom.xml files in openmrs-api, openmrs-web, or >>> openmrs-webapp, I get this message: >>> Plugin execution not covered by lifecycle configuration: >>> com.googlecode.maven-java-formatter-plugin:maven-java-formatter-plugin:0.3:format >>> (execution: default, phase: process-sources) >>> >>> I'm kind of at a loss here. Suggestions are welcome. >>> >>> -Darius >>> >> >> > _________________________________________ To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to [email protected] with "SIGNOFF openmrs-devel-l" in the body (not the subject) of your e-mail. [mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l]
