Hi, I think the workaround Rowan did by adding the mapping manually reveal a problem with the way we package the module. Right now what we have in the API layer for a mavenized module is just the class file only and the output from the API layer for a module is just the java class file for that module. With the current approach, we won't be able to do unit testing on the API layer because there's no configuration to wire the DAO and Service layer. And if we want to include the API layer of another module, we will end up with the same situation as above (maybe adding the omod as dependency, instead of the api would fix the above problem!)
I think the better way to package the module is putting the class files and hbm and spring configuration in the api layer. With this approach we will have a better separation between the API and the web layer for the module itself. API will contains all the beans for that module and omod will contains the API jar file and the web layer for the module. Somewhat related question from me in the answers website: https://answers.openmrs.org/questions/85/how-does-maven-replace-hbm-filenames-in-test-hibernatecfgxml On Thu, Nov 3, 2011 at 12:04 PM, Rowan Seymour <[email protected]> wrote: > I edited test-hibernate.cfg.xml to explicitly include the TokenRegistration > mapping file and that seems to fix the unknown entity exception, i.e. > > <hibernate-configuration> > <session-factory> > ${hbmConfig} > <mapping resource="TokenRegistration.hbm.xml" /> > </session-factory> > </hibernate-configuration> > > But now those 3 unit tests are failing with another exception... > java.lang.NoSuchMethodError: > org.openmrs.logic.LogicContext.eval(Ljava/lang/Integer;Lorg/openmrs/logic/LogicCriteria;Ljava/util/Map;)Lorg/openmrs/logic/result/Result; > I've looked at the source for LogicContext and it appears that between > OpenMRS 1.7 and 1.8 it's eval methods switched from using Patient objects as > parameters, to using integers. The same switch occurred in LogicContextImpl > in the logic module between 0.4 and 0.5 > So I need to depend on version 0.4 of the logic module which isn't in the > maven repository. Can someone who knows more about this module put it in > maven? Does html form entry work with OpenMRS 1.8? > On 3 November 2011 15:50, Rowan Seymour <[email protected]> wrote: >> >> It's using logic 0.5 same as Mark just showed. The 3 failing tests are: >> >> applyExcludes_shouldReturnCorrectXmlAfterApplyExcludeIfTag(org.openmrs.module.htmlformentry.HtmlFormEntryGeneratorTest): >> Unknown entity: org.openmrs.logic.token.TokenRegistration >> >> applyIncludes_shouldReturnCorrectXmlAfterApplyIncludeTag(org.openmrs.module.htmlformentry.HtmlFormEntryGeneratorTest): >> Unknown entity: org.openmrs.logic.token.TokenRegistration >> >> processIncludeLogic_shouldReturnACorrectBooleanValueForLogicTestString(org.openmrs.module.htmlformentry.HtmlFormEntryGeneratorTest): >> Unknown entity: org.openmrs.logic.token.TokenRegistration >> Stack trace just shows that it didn't recognize TokenRegistration as an >> entity.... >> >> applyExcludes_shouldReturnCorrectXmlAfterApplyExcludeIfTag(org.openmrs.module.htmlformentry.HtmlFormEntryGeneratorTest) >> Time elapsed: 0.255 sec <<< ERROR! >> org.hibernate.MappingException: Unknown entity: >> org.openmrs.logic.token.TokenRegistration >> at >> org.hibernate.impl.SessionFactoryImpl.getEntityPersister(SessionFactoryImpl.java:550) >> at >> org.hibernate.impl.SessionImpl.getEntityPersister(SessionImpl.java:1338) >> at org.hibernate.engine.ForeignKeys.isTransient(ForeignKeys.java:180) >> at >> org.hibernate.event.def.AbstractSaveEventListener.getEntityState(AbstractSaveEventListener.java:512) >> at >> org.hibernate.event.def.DefaultSaveOrUpdateEventListener.performSaveOrUpdate(DefaultSaveOrUpdateEventListener.java:80) >> at >> org.hibernate.event.def.DefaultSaveOrUpdateEventListener.onSaveOrUpdate(DefaultSaveOrUpdateEventListener.java:70) >> at org.hibernate.impl.SessionImpl.fireSaveOrUpdate(SessionImpl.java:507) >> at org.hibernate.impl.SessionImpl.saveOrUpdate(SessionImpl.java:499) >> at org.hibernate.impl.SessionImpl.saveOrUpdate(SessionImpl.java:495) >> at >> org.openmrs.logic.token.db.hibernate.HibernateTokenDAO.saveTokenRegistration(HibernateTokenDAO.java:118) >> 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.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:307) >> at >> org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:182) >> at >> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:149) >> at >> org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:106) >> at >> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171) >> at >> org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204) >> at $Proxy73.saveTokenRegistration(Unknown Source) >> at >> org.openmrs.logic.token.impl.TokenServiceImpl.saveTokenRegistration(TokenServiceImpl.java:316) >> 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.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:307) >> at >> org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:182) >> at >> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:149) >> at org.openmrs.aop.LoggingAdvice.invoke(LoggingAdvice.java:107) >> at >> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171) >> at >> org.springframework.aop.framework.adapter.MethodBeforeAdviceInterceptor.invoke(MethodBeforeAdviceInterceptor.java:50) >> at >> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171) >> at >> org.springframework.aop.framework.adapter.MethodBeforeAdviceInterceptor.invoke(MethodBeforeAdviceInterceptor.java:50) >> at >> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171) >> at >> org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204) >> at $Proxy74.saveTokenRegistration(Unknown Source) >> 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.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:307) >> at >> org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:198) >> at $Proxy82.saveTokenRegistration(Unknown Source) >> at >> org.openmrs.logic.token.impl.TokenServiceImpl.registerToken(TokenServiceImpl.java:207) >> 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.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:307) >> at >> org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:182) >> at >> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:149) >> at org.openmrs.aop.LoggingAdvice.invoke(LoggingAdvice.java:107) >> at >> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171) >> at >> org.springframework.aop.framework.adapter.MethodBeforeAdviceInterceptor.invoke(MethodBeforeAdviceInterceptor.java:50) >> at >> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171) >> at >> org.springframework.aop.framework.adapter.MethodBeforeAdviceInterceptor.invoke(MethodBeforeAdviceInterceptor.java:50) >> at >> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171) >> at >> org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204) >> at $Proxy74.registerToken(Unknown Source) >> 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.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:307) >> at >> org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:198) >> at $Proxy82.registerToken(Unknown Source) >> at >> org.openmrs.logic.util.LogicUtil.registerDefaultRules(LogicUtil.java:111) >> at >> org.openmrs.module.htmlformentry.HtmlFormEntryGeneratorTest.applyExcludes_shouldReturnCorrectXmlAfterApplyExcludeIfTag(HtmlFormEntryGeneratorTest.java:37) >> 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.springframework.test.context.junit4.SpringTestMethod.invoke(SpringTestMethod.java:160) >> at >> org.springframework.test.context.junit4.SpringMethodRoadie.runTestMethod(SpringMethodRoadie.java:233) >> at >> org.springframework.test.context.junit4.SpringMethodRoadie$RunBeforesThenTestThenAfters.run(SpringMethodRoadie.java:333) >> at >> org.springframework.test.context.junit4.SpringMethodRoadie.runWithRepetitions(SpringMethodRoadie.java:217) >> at >> org.springframework.test.context.junit4.SpringMethodRoadie.runTest(SpringMethodRoadie.java:197) >> at >> org.springframework.test.context.junit4.SpringMethodRoadie.run(SpringMethodRoadie.java:143) >> at >> org.springframework.test.context.junit4.SpringJUnit4ClassRunner.invokeTestMethod(SpringJUnit4ClassRunner.java:160) >> at >> org.junit.internal.runners.JUnit4ClassRunner.runMethods(JUnit4ClassRunner.java:51) >> at >> org.junit.internal.runners.JUnit4ClassRunner$1.run(JUnit4ClassRunner.java:44) >> at >> org.junit.internal.runners.ClassRoadie.runUnprotected(ClassRoadie.java:27) >> at >> org.junit.internal.runners.ClassRoadie.runProtected(ClassRoadie.java:37) >> at >> org.junit.internal.runners.JUnit4ClassRunner.run(JUnit4ClassRunner.java:42) >> at >> org.springframework.test.context.junit4.SpringJUnit4ClassRunner.run(SpringJUnit4ClassRunner.java:97) >> at >> org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:53) >> at >> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:123) >> at >> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:104) >> 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.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:164) >> at >> org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:110) >> at >> org.apache.maven.surefire.booter.SurefireStarter.invokeProvider(SurefireStarter.java:175) >> at >> org.apache.maven.surefire.booter.SurefireStarter.runSuitesInProcessWhenForked(SurefireStarter.java:107) >> at >> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:68) >> >> On 3 November 2011 15:34, Mark Goodrich <[email protected]> wrote: >>> >>> It sounds like you’ve already done this, but tf you haven’t added logic >>> as a dependency, definitely try that. These are the dependancies I had to >>> add to patient flags omod pom to get the test scripts to run: >>> >>> >>> >>> <!-- dependencies required for testing --> >>> >>> <dependency> >>> >>> <groupId>cglib</groupId> >>> >>> <artifactId>cglib</artifactId> >>> >>> <type>jar</type> >>> >>> <version>2.2.2</version> >>> >>> <scope>test</scope> >>> >>> </dependency> >>> >>> >>> >>> <dependency> >>> >>> <groupId>org.openmrs.module</groupId> >>> >>> <artifactId>logic</artifactId> >>> >>> <type>jar</type> >>> >>> <version>0.5</version> >>> >>> <scope>test</scope> >>> >>> </dependency> >>> >>> >>> >>> From: [email protected] [mailto:[email protected]] On Behalf Of Rowan Seymour >>> Sent: Thursday, November 03, 2011 8:45 AM >>> >>> To: [email protected] >>> Subject: Re: [OPENMRS-DEV] FW: HTML form entry changes >>> >>> >>> >>> They're all passing but 3 now. Realised that I could see the complete >>> exceptions from the unit tests in target/surefire-reports, and so noticed >>> that it was missing a cglib dependency. So I've added that, but 3 tests are >>> still failing with: >>> >>> >>> >>> "Unknown entity: org.openmrs.logic.token.TokenRegistration" >>> >>> >>> >>> ... which I think means that although logic is being loaded ok as a >>> dependency, it's not finding the TokenRegistration.hbm.xml mapping file. >>> Need to figure out the black magic which loads mapping files... >>> >>> On 3 November 2011 13:56, Rowan Seymour <[email protected]> wrote: >>> >>> Love dat undocumented maven black magic. When I ran the mavenization >>> script the config.xml ended up like: >>> >>> >>> >>> ... >>> >>> <mappingFiles> >>> </mappingFiles> >>> >>> ... >>> >>> >>> >>> but it needs that variable: >>> >>> ... >>> >>> <mappingFiles> >>> ${omodHbmConfig} >>> </mappingFiles> >>> >>> ... >>> >>> >>> >>> I'm mavenizing the logmanager module as well for kicks and that's fixed >>> it now, but htmlformentry unit tests are still failing with "Failed to load >>> ApplicationContext". Maybe because htmlformentry has multiple Spring >>> application context files? There's TestingApplicationContext.xml in the >>> original module and one with the same name generated by the mavenization >>> script. Merged them but that didn't help. >>> >>> >>> >>> On 3 November 2011 12:30, Ben Wolfe <[email protected]> wrote: >>> >>> The formentry module has hbm files and its tests pass. >>> >>> There is more black magic happening than you know. The config.xml file >>> is updated with the mapping file names when you build. There is a "maven >>> openmrs module" plugin that the omod pom.xml file refers to that does that >>> during the package (?) phase. >>> >>> Ben >>> >>> >>> >>> On Thu, Nov 3, 2011 at 12:59 PM, Rowan Seymour <[email protected]> >>> wrote: >>> >>> I've looked at some examples of other mavenized modules that work. Has >>> anyone mavenized a module that still uses Hibernate .hbm.xml mapping files? >>> Since the references to these are removed from config.xml by the >>> mavenization script, what is the new mechanism for declaring them? >>> >>> >>> >>> On 3 November 2011 09:32, Rowan Seymour <[email protected]> wrote: >>> >>> Done http://svn.openmrs.org/openmrs-modules/htmlformentry/tags/pre-maven/ >>> >>> >>> >>> Still stuck on these failing unit tests >>> >>> >>> >>> >>> >>> On 2 November 2011 17:16, Darius Jazayeri <[email protected]> >>> wrote: >>> >>> Could someone please tag the module in svn as "pre-maven" right before >>> committing the mavenization? >>> >>> >>> >>> -Darius >>> >>> >>> >>> On Wed, Nov 2, 2011 at 8:01 AM, Mark Goodrich <[email protected]> wrote: >>> >>> I would say as long as you can successfully test and package the module >>> via mvn, it is okay to commit… did you overcome the problem with testing via >>> maven? >>> >>> >>> >>> Mark >>> >>> >>> >>> From: [email protected] [mailto:[email protected]] On Behalf Of Rowan Seymour >>> Sent: Wednesday, November 02, 2011 10:31 AM >>> >>> To: [email protected] >>> Subject: Re: [OPENMRS-DEV] FW: HTML form entry changes >>> >>> >>> >>> Here's the omod's dependencies at the mo... >>> >>> >>> >>> Btw I assume's it's ok for me to check this back into SVN while we >>> continue working on the junit problems? >>> >>> >>> >>> <dependencies> >>> >>> <dependency> >>> >>> <groupId>org.openmrs.module</groupId> >>> >>> >>> <artifactId>htmlformentry-api</artifactId> >>> >>> >>> <version>${project.parent.version}</version> >>> >>> </dependency> >>> >>> <dependency> >>> >>> <groupId>org.openmrs.module</groupId> >>> >>> <artifactId>logic</artifactId> >>> >>> <version>0.5</version> >>> >>> </dependency> >>> >>> <dependency> >>> >>> <groupId>org.openmrs.api</groupId> >>> >>> <artifactId>openmrs-api</artifactId> >>> >>> <type>jar</type> >>> >>> </dependency> >>> >>> <dependency> >>> >>> <groupId>org.openmrs.web</groupId> >>> >>> <artifactId>openmrs-web</artifactId> >>> >>> <type>jar</type> >>> >>> </dependency> >>> >>> <dependency> >>> >>> <groupId>org.openmrs.test</groupId> >>> >>> <artifactId>openmrs-test</artifactId> >>> >>> <type>jar</type> >>> >>> <scope>test</scope> >>> >>> </dependency> >>> >>> <dependency> >>> >>> >>> <groupId>org.codehaus.groovy</groupId> >>> >>> <artifactId>groovy</artifactId> >>> >>> <version>1.8.3</version> >>> >>> <type>jar</type> >>> >>> <scope>test</scope> >>> >>> </dependency> >>> >>> </dependencies> >>> >>> >>> >>> On 2 November 2011 16:06, Mark Goodrich <[email protected]> wrote: >>> >>> Rowen— >>> >>> >>> >>> Does the omod pom.xml contain dependencies to the htmlformentry-api, as >>> well as the org.openmrs.api, org.openmrs.web, and org.openmrs.test? >>> >>> >>> >>> Mark >>> >>> >>> >>> >>> >>> From: [email protected] [mailto:[email protected]] On Behalf Of Rowan Seymour >>> Sent: Wednesday, November 02, 2011 9:33 AM >>> To: [email protected] >>> Subject: Re: [OPENMRS-DEV] FW: HTML form entry changes >>> >>> >>> >>> Sorry actually I'm getting the same "Failed to load ApplicationContext" >>> error when I run them from maven but the groovy error when I run them from >>> eclipse. I even added groovy as dependency but that isn't fixing it... >>> >>> <dependency> >>> <groupId>org.codehaus.groovy</groupId> >>> <artifactId>groovy</artifactId> >>> <version>1.8.3</version> >>> <type>jar</type> >>> <scope>test</scope> >>> </dependency> >>> >>> On 2 November 2011 14:41, Rowan Seymour <[email protected]> wrote: >>> >>> Yes, maven and those scripts >>> >>> >>> >>> I've now noticed that the maven migration script generated the file >>> omod/src/test/resources/test-hibernate.cfg.xml whose content is: >>> >>> >>> >>> <hibernate-configuration> >>> <session-factory> >>> ${hbmConfig} >>> </session-factory> >>> </hibernate-configuration> >>> >>> >>> >>> This seems to be the source of the SAX exception below. It also removed >>> the hibernate mappings from config.xml. Should ${hbmConfig} have been >>> expanded at mavenization time? >>> >>> >>> >>> If I added the mapping file manually, like >>> >>> >>> >>> <hibernate-configuration> >>> <session-factory> >>> <mapping resource="HtmlFormEntryHtmlForm.hbm.xml"/> >>> </session-factory> >>> </hibernate-configuration> >>> >>> >>> >>> ... then it seems to fix the tests tho now I've got groovy "class not >>> found" exceptions... >>> >>> >>> >>> On 2 November 2011 14:24, Ben Wolfe <[email protected]> wrote: >>> >>> Are your tests in the omod project? >>> How are you running tests? >>> Did you use the mavenize scripts here? >>> https://wiki.openmrs.org/display/docs/Converting+old+code+to+Maven >>> >>> Ben >>> >>> >>> >>> On Wed, Nov 2, 2011 at 3:06 PM, Rowan Seymour <[email protected]> >>> wrote: >>> >>> Have started the mavenization - can build the module no prob and it seems >>> to work fine in OpenMRS... but can't run the unit tests. When I do I get the >>> following exceptions on any test requiring an OpenMRS context... >>> >>> >>> >>> Any ideas?? >>> >>> >>> >>> java.lang.IllegalStateException: Failed to load ApplicationContext >>> >>> at >>> org.springframework.test.context.TestContext.getApplicationContext(TestContext.java:201) >>> >>> at >>> org.springframework.test.context.support.DependencyInjectionTestExecutionListener.injectDependencies(DependencyInjectionTestExecutionListener.java:109) >>> >>> at >>> org.springframework.test.context.support.DependencyInjectionTestExecutionListener.prepareTestInstance(DependencyInjectionTestExecutionListener.java:75) >>> >>> at >>> org.springframework.test.context.TestContextManager.prepareTestInstance(TestContextManager.java:255) >>> >>> ... >>> >>> ... 49 more >>> >>> Caused by: org.springframework.beans.factory.BeanCreationException: Error >>> creating bean with name 'sessionFactory' defined in URL >>> [file:/Users/rowan/Workspaces/OpenMRS/htmlformentry/omod/target/test-classes/TestingApplicationContext.xml]: >>> Invocation of init method failed; nested exception is >>> org.hibernate.MappingException: invalid configuration >>> >>> at >>> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapable.. >>> >>> >>> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1335) >>> >>> ... 72 more >>> >>> Caused by: org.xml.sax.SAXParseException: The content of element type >>> "session-factory" must match >>> "(property*,mapping*,(class-cache|collection-cache)*,event*,listener*)". >>> >>> at >>> org.apache.xerces.util.ErrorHandlerWrapper.createSAXParseException(Unknown >>> Source) >>> >>> at org.apache.xerces.util.ErrorHandlerWrapper.error(Unknown Source) >>> >>> at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown Source) >>> >>> at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown Source) >>> >>> at org.apache.xerces.impl.dtd.XMLDTDValidator.handleEndElement(Unknown >>> Source) >>> >>> at org.apache.xerces.impl.dtd.XMLDTDValidator.endElement(Unknown Source) >>> >>> at org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanEndElement(Unknown >>> Source) >>> >>> at >>> org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown >>> Source) >>> >>> at >>> org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown >>> Source) >>> >>> at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) >>> >>> at org.apache.xerces.parsers.DTDConfiguration.parse(Unknown Source) >>> >>> at org.apache.xerces.parsers.XMLParser.parse(Unknown Source) >>> >>> at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source) >>> >>> at org.dom4j.io.SAXReader.read(SAXReader.java:465) >>> >>> at org.hibernate.cfg.Configuration.doConfigure(Configuration.java:1484) >>> >>> ... 78 more >>> >>> >>> >>> >>> >>> On 1 November 2011 20:59, Mark Goodrich <[email protected]> wrote: >>> >>> When using the script on the openmrs wiki to convert modules to maven, >>> three projects are created: >>> >>> >>> >>> module >>> >>> module-api >>> >>> module-parent >>> >>> >>> >>> Is there an updated version of the script anywhere that creates the >>> following three projects instead: >>> >>> >>> >>> module >>> >>> module-api >>> >>> module-omod >>> >>> >>> >>> I see that this was the way the logic module was set up. This makes more >>> intuitive sense, and I would think this would be the convention we’d want to >>> follow. >>> >>> >>> >>> Mark >>> >>> >>> >>> From: [email protected] [mailto:[email protected]] On Behalf Of >>> Rowan Seymour >>> Sent: Tuesday, November 01, 2011 2:46 PM >>> To: Mark Goodrich >>> Cc: Darius Jazayeri-Gmail; Yekkanti Kishore Kumar; Dave Thomas; Christian >>> Neumann; Desire Ruzigana; Jean Damascene Habana; Gapepwe Ali; Evan Waters; >>> Michael Seaton; Michael Downey >>> >>> Subject: Re: HTML form entry changes >>> >>> >>> >>> We'll have a stab at it tomorrow and see if we run into any problems. >>> I've also noticed that the script doesn't always parse config.xml correctly >>> because it read my module id as " <id>logmanager</id>" with the tags. >>> >>> >>> >>> The scripts need updated if this is the OpenMRS convention - seems that >>> Matt Blanchette has been maintaining them so maybe he wants to update them? >>> >>> On 1 November 2011 20:44, Mark Goodrich <[email protected]> wrote: >>> >>> I second Darius on this… I mavenized the mdr-tb and the patient flags >>> module and ended up with the “module, module-api, and module-parent setup”, >>> which was annoying. The conversion script that I used (taken from the >>> openmrs wiki) did this…. I don’t know if there is an updated/different >>> version of the script that does it the better/more intuitive way? >>> >>> >>> >>> @Rowan: I may have some time this week to mavenize the module if you >>> don’t get to it. Basically, after you run the script, you have to go >>> through and determine what dependencies you have to add to the poms. >>> >>> >>> >>> Mark >>> >>> >>> >>> >>> >>> From: Darius Jazayeri [mailto:[email protected]] >>> Sent: Tuesday, November 01, 2011 2:30 PM >>> To: Rowan Seymour >>> Cc: Yekkanti Kishore Kumar; Mark Goodrich; Dave Thomas; Christian >>> Neumann; Desire Ruzigana; Jean Damascene Habana; Gapepwe Ali; Evan Waters; >>> Michael Seaton; Michael Downey >>> >>> Subject: Re: HTML form entry changes >>> >>> >>> >>> Hi Rowan, >>> >>> >>> >>> I think you can just go ahead and do it. >>> >>> >>> >>> Do please make sure we end up with the model of: >>> >>> htmlformentry >>> >>> htmlformentry-api >>> >>> htmlformentry-omod >>> >>> >>> >>> rather than the model with a -parent module. >>> >>> >>> >>> -Darius >>> >>> On Tue, Nov 1, 2011 at 11:22 AM, Rowan Seymour <[email protected]> wrote: >>> >>> Ok excellent - so any objections to mavenizing this module? >>> >>> >>> >>> Any volunteers to do the mavenizing? I'm practicing on my logmanager >>> module with the conversion scripts and it seems easy enough so maybe we can >>> do it? >>> >>> >>> >>> I've attached an updated authors.txt - this will be a useful resource to >>> build on for any future git migrations but it does contain email addresses >>> so I don't want to put it on the wiki >>> >>> >>> >>> >>> >>> On 1 November 2011 20:20, Yekkanti Kishore Kumar >>> <[email protected]> wrote: >>> >>> I'm pretty much occupied this week. I can do it on Monday, if it is not >>> too late. I think this will also give us some decent time to mavenize the >>> module. >>> >>> >>> >>> I'm based out of Chennai, India. >>> >>> >>> >>> On Tue, Nov 1, 2011 at 8:03 PM, Mark Goodrich <[email protected]> wrote: >>> >>> Agreed that it might make sense to mavenize it first since we all have to >>> make don’t have any uncommitted changes anyway. >>> >>> >>> >>> Mark >>> >>> >>> >>> From: [email protected] [mailto:[email protected]] On Behalf Of >>> Rowan Seymour >>> Sent: Tuesday, November 01, 2011 10:26 AM >>> To: Yekkanti Kishore Kumar >>> Cc: Mark Goodrich; Dave Thomas; Darius Jazayeri-Gmail; Christian Neumann; >>> Desire Ruzigana; Jean Damascene Habana; Gapepwe Ali; Evan Waters; Michael >>> Seaton; Michael Downey >>> >>> Subject: Re: HTML form entry changes >>> >>> >>> >>> Maybe you can do the migration - my internet is woeful and it's been >>> churning away all afternoon with no end in site and it sounds like you're a >>> git guru :) I assume you're based somewhere with decent internet? >>> >>> >>> >>> Makes me wonder if this module shouldn't be maven'ised and then migrated >>> without the history of JAR files - I think that svn2git script lets you >>> exclude directories so maybe we could exclude lib-common ? >>> >>> >>> >>> Michael Downey (cc'd) can give you the right permissions to upload the >>> final git repository under the OpenMRS git hub organization. >>> >>> >>> >>> I've attached the authors file I was using - the only username I don't >>> have a mapping for is "gbalaji" so I made up one.... >>> >>> >>> >>> Thanks >>> >>> >>> >>> Rowan >>> >>> On 1 November 2011 12:03, Yekkanti Kishore Kumar >>> <[email protected]> wrote: >>> >>> Ohh thats awesome. Me too on OSX. So, in OSX if you installed git using >>> brew then you NEED NOT install git-svn. It comes by default. >>> >>> So now you can go ahead and checkout using git svn clone http:/../.. >>> (dont' keep a '-' between git and svn) >>> >>> >>> >>> On Tue, Nov 1, 2011 at 3:22 PM, Rowan Seymour <[email protected]> wrote: >>> >>> I'm on OSX - I have git-core installed through homebrew but there doesn't >>> seem to be a git-svn package, so I was looking for the downloads on >>> kernel.org. >>> >>> >>> >>> I suppose I could just use a ubuntu box for the migration... >>> >>> >>> >>> On 1 November 2011 11:49, Yekkanti Kishore Kumar >>> <[email protected]> wrote: >>> >>> Rowan, >>> >>> you need to have git-core before installing git-svn. I'm not sure whey >>> you were unable to find git-svn package. >>> >>> This might help http://blog.coralic.nl/2010/01/15/git-svn-and-ubuntu/ >>> >>> >>> >>> On Mon, Oct 31, 2011 at 7:35 PM, Mark Goodrich <[email protected]> wrote: >>> >>> I don’t have any checked out changes, so I’m good to go. >>> >>> >>> >>> Whatever we decide to do, I vote we don’t go with trying to keep the two >>> repos in sync… >>> >>> >>> >>> I also agree that using Git for the student projects is a good idea, to >>> make sure that we keep the current trunk of htmlformentry as stable as >>> possible… we dodged a bullet with an insidious bug we introduced a few >>> months back. >>> >>> >>> >>> On a more general note, I’ve come back from Rwanda with a list of >>> HtmlformEntry feature requests from the Rwanda PIH team. I have to discuss >>> with Evan and Mike what the actual priority of these features are, but we >>> should make sure we keep our work in sync with what the students are doing. >>> >>> >>> >>> Take care, >>> >>> Mark >>> >>> >>> >>> From: [email protected] [mailto:[email protected]] On Behalf Of >>> Rowan Seymour >>> Sent: Monday, October 31, 2011 7:37 AM >>> To: Yekkanti Kishore Kumar >>> Cc: Dave Thomas; Darius Jazayeri-Gmail; Christian Neumann; Desire >>> Ruzigana; Jean Damascene Habana; Gapepwe Ali; Mark Goodrich >>> Subject: Re: HTML form entry changes >>> >>> >>> >>> I tried github's built-in SVN >>> import http://help.github.com/import-from-subversion/ but it hangs when >>> trying to fetch the svn author list >>> >>> >>> >>> Can't find a download for git-svn (kernel.org is undergoing a >>> re-organization - any ideas?) so am gonna try svn2git as you recommend. >>> >>> >>> >>> I'll post something to the dev list so everyone knows what we're planning >>> >>> On 31 October 2011 11:50, Yekkanti Kishore Kumar >>> <[email protected]> wrote: >>> >>> Really good idea to move HtmlFormEntry to github. >>> >>> Two different things are possible >>> >>> Moving the complete repo(with history) from svn to github (might be some >>> where in https://github.com/openmrs) and remove the repo from SVN, so that >>> we'll use github moving forward. >>> Moving the repo(with history) to github but sill persisting the svn repo. >>> Advantage we get from this is, we'll not pollute over svn repo immediately >>> and eventually moving forward we can deprecate svn repo and use github >>> alone. Disadvantage is we need to keep both svn and github repos in synch as >>> there would be some kind of development in both the repos. >>> >>> As far as moving the repo from svn to github is very straight forward. >>> I'm sure Rowan will already know how to do it. >>> >>> I personally prefer any one of the below >>> >>> Using https://github.com/nirvdrum/svn2git scirpt. This will allow you to >>> move code from svn to github seamlessly >>> We can do it manually by first checking out the code through git-svn. Ex: >>> git svn clone http://../htmlformentry. And then point the remotes of git >>> configuration to the github url you want your code to be. >>> >>> >>> >>> On Mon, Oct 31, 2011 at 1:21 PM, Rowan Seymour <[email protected]> wrote: >>> >>> I've once moved an SVN project from Google code to Git on Github so I >>> could have a stab at setting it up. Just need to be sure everything is >>> committed and everyone is on board. >>> >>> >>> >>> Rowan >>> >>> >>> >>> On 30 October 2011 19:15, Dave Thomas <[email protected]> wrote: >>> >>> nope, nothing new to commit here. I'm game to be a client of the >>> switch, although i'd prefer not to be the one doing the switch... >>> >>> d >>> >>> On 10/29/11, Darius Jazayeri <[email protected]> wrote: >>> > I'm copying Mark, who is a more active owner of HTML Form Entry than I >>> > am >>> > these days. >>> > >>> > I agree about taking this opportunity to try out git. Is anyone opposed >>> > to >>> > moving the primary location to github? >>> > >>> > Does anyone (Mark? Dave?) have outstanding code to commit? >>> > >>> > Does someone have time to actually move the code over from svn to >>> > github? >>> > (Copying Kishore to comment on whether that's an easy step or a >>> > complicated >>> > one, and how much work it would be to preserve history.) >>> > >>> > -Darius >>> > >>> > On Sat, Oct 29, 2011 at 12:13 AM, Christian Neumann >>> > <[email protected]>wrote: >>> > >>> >> I agree that git is much more efficient and suitable for slow, >>> >> high-latency connections. In Neno SVN is a pain. A commit of a single >>> >> file >>> >> usually takes 20+ seconds. Checking out modules with all their >>> >> hardcoded >>> >> dependencies (pre Maven) is a task for the night. More advanced things >>> >> like >>> >> branching or extended comparing are not possible due to my lack of >>> >> patience. >>> >> >>> >> git for my local projects and our partners (Baobab/innoQ) is much more >>> >> applicable. Although in my experience (especially for people coming >>> >> from >>> >> the central SVN approach) it can be confusing to fork extensively >>> >> between >>> >> different repositories/computers. Maybe try to keep a local master for >>> >> the >>> >> beginning as well. >>> >> >>> >> christian >>> >> >>> >> On Oct 28, 2011, at 11:11 AM, Rowan Seymour wrote: >>> >> >>> >> >>> >> >>> >> >>> >> Recently we talked about git-izing a module as an experiment and >>> >> someone >>> >> suggested HTML Form Entry. My first thought was "arghhh that'll make >>> >> it >>> >> even harder for the students to work on it" but having thought about >>> >> it I >>> >> think it would make our lives a lot easier. This is a scenario where >>> >> git >>> >> shines. >>> >> >>> >> Making these changes to HTML Form Entry will require a bit of >>> >> experimentation so it would not be a good idea to be checking changes >>> >> directly into the OpenMRS SVN repository. We also haven't had internet >>> >> for >>> >> the last two days This would mean we'd have to create our own locally >>> >> hosted branch in SVN and whatever changes work at the end of this >>> >> project >>> >> would be merged back into the trunk… which I've never actually done >>> >> with >>> >> SVN but I gather it's not a lot of fun. >>> >> >>> >> It sounds like it would be much easier in git world. We fork the >>> >> module on >>> >> github and that becomes our working copy. The students can fork that >>> >> locally and have local copies for when the internet doesn't work and >>> >> if >>> >> they need to do some serious experimentation they can just keep >>> >> forking. >>> >> Eventually if we've made something that works we give you guys pull >>> >> requests. >>> >> >>> >> If it's ok with you guys we're ready to be part of the OpenMRS git >>> >> experiment... >>> >> >>> >> Including Dave for his thoughts as well >>> >> >>> >> Rowan >>> >> >>> >> >>> >> On 26 October 2011 16:25, Rowan Seymour <[email protected]<mailto: >>> >> [email protected]>> wrote: >>> >> @Christian - I'd like to introduce you to the students that are going >>> >> to >>> >> be working on the different HTML form entry changes you suggested. I >>> >> don't >>> >> know if we'll be able to do all these changes but we'll try and see >>> >> what's >>> >> possible. >>> >> >>> >> @Darius - as an expert on HTML Form Entry we'd appreciate your >>> >> thoughts on >>> >> these proposed changes >>> >> >>> >> @Students - meet Christian from Malawi who has requested these changes >>> >> and >>> >> will be deploying your projects if they work :) >>> >> >>> >> Here are the original specifications from Christian with my >>> >> questions/thoughts in italics... >>> >> >>> >> Preset provider, encounter location, and encounter date >>> >> Data entry activity usually happens within the context of a clinic >>> >> day. A >>> >> clinic falls on a specific day (maybe Tuesday's ART clinic), has >>> >> sometimes >>> >> (most of the times for us) the same provider assigned for this day and >>> >> happens at one location (either the central place or one of the remote >>> >> clinics). So 100 patients for _that_ day, receiving care at _that_ >>> >> facility >>> >> and are treated by _that_ provider need to be entered. These data >>> >> points >>> >> are almost always the same, yet they are entered for every single >>> >> encounter. My over-simplified 'click-count' reaches high numbers to >>> >> enter >>> >> always the same data, inefficient and error-prone. Would be cool if >>> >> the >>> >> user could pre-set these values for a data entry activity. Maybe a >>> >> clever >>> >> (hacky?) DOM manipulation can simply look for encounter date, >>> >> encounter >>> >> location, and provider dropdown boxes to select the one the others had >>> >> selected. (Maybe there can be an Admin section or an extension to the >>> >> profile page or simply a new box at the patient overview). >>> >> >>> >> Should this be controlled by the form designer or the entry clerk? We >>> >> could have an attribute like remember="session" that allows field >>> >> values >>> >> to >>> >> be remembered across different submissions but then it would be up to >>> >> the >>> >> form designer to enable this. Alternatively there could be a memory >>> >> set/recall button at the bottom of the form which the data entry clerk >>> >> can >>> >> use to remember whatever values he chooses >>> >> >>> >> Suggest next appointment date >>> >> Appointment dates usually follow rules. These can be pretty complex, >>> >> but >>> >> in a nutshell ART patients usually receive 1, 2, or 3 months >>> >> appointment >>> >> dates. Using the date picker it shows the current month. Which in 95% >>> >> of >>> >> the cases is not the right one. Either the appointment date HFE tag >>> >> can >>> >> take at least or parameter to say the 'default RVD is 2 months' or >>> >> even >>> >> has >>> >> some simple logic to calc this from the prescribed drugs or another >>> >> Obs >>> >> value (like number of pills given to patient). And if we already touch >>> >> code >>> >> for this, maybe we should prevent appointment dates before encounter >>> >> dates >>> >> together with too far ahead appointment dates. >>> >> >>> >> I imagine this would be an attribute on the obs tag something like >>> >> defaultDate="+2months" ? It would also force that date to be on a >>> >> weekday >>> >> >>> >> HTML Form Program enrollment >>> >> Editing the program enrollments directly in the HTML Forms would be >>> >> helpful (so far we only have readonly access). Usually the encounter >>> >> type >>> >> already drives the program and states to select (a PART_INITIAL for >>> >> Pre-ART, ART_INITIAL for On ART, ...). The enrollment location (at >>> >> least >>> >> most of the times) will be the encounter location and the encounter >>> >> date >>> >> will be the enrollment date and/or state transition. These fields >>> >> could be >>> >> pre-populated and the user could overwrite them for the few >>> >> exceptions. >>> >> Adding a 'quick transfer' from one facility to another and I could >>> >> retire >>> >> the program section (and my recent 'Quick programs') from the >>> >> Dashboard. >>> >> >>> >> This is the harder one I think because it means new code in several >>> >> places. FormSubmissionAction has the code to enroll a patient in a >>> >> program >>> >> but we'd change it to take those values from fields on the form. >>> >> >>> >> -- >>> >> >>> >> Dr Rowan Seymour >>> >> Partners In Health, Rwanda >>> >> Tel: +250783835665<tel:%2B250783835665> >>> >> >>> >> >>> >> >>> >> >>> >> -- >>> >> >>> >> Dr Rowan Seymour >>> >> Partners In Health, Rwanda >>> >> Tel: +250783835665 >>> >> >>> >> >>> >> >>> > >>> >>> >>> >>> -- >>> >>> Dr Rowan Seymour >>> Partners In Health, Rwanda >>> Tel: +250783835665 >>> >>> >>> >>> >>> >>> -- >>> Regards, >>> Kishore Kumar Yekkanti. >>> >>> >>> >>> -- >>> >>> Dr Rowan Seymour >>> Partners In Health, Rwanda >>> Tel: +250783835665 >>> >>> >>> >>> >>> >>> -- >>> Regards, >>> Kishore Kumar Yekkanti. >>> >>> >>> >>> -- >>> >>> Dr Rowan Seymour >>> Partners In Health, Rwanda >>> Tel: +250783835665 >>> >>> >>> >>> >>> >>> -- >>> Regards, >>> Kishore Kumar Yekkanti. >>> >>> >>> >>> -- >>> >>> Dr Rowan Seymour >>> Partners In Health, Rwanda >>> Tel: +250783835665 >>> >>> >>> >>> >>> >>> -- >>> Regards, >>> Kishore Kumar Yekkanti. >>> >>> >>> >>> -- >>> >>> Dr Rowan Seymour >>> Partners In Health, Rwanda >>> Tel: +250783835665 >>> >>> >>> >>> >>> >>> >>> >>> -- >>> >>> Dr Rowan Seymour >>> Partners In Health, Rwanda >>> Tel: +250783835665 >>> >>> >>> >>> ________________________________ >>> >>> Click here to unsubscribe from OpenMRS Developers' mailing list >>> >>> >>> >>> -- >>> Rowan Seymour >>> tel: +250 783835665 >>> http://twitter.com/rowanseymour >>> >>> >>> >>> ________________________________ >>> >>> Click here to unsubscribe from OpenMRS Developers' mailing list >>> >>> >>> >>> ________________________________ >>> >>> Click here to unsubscribe from OpenMRS Developers' mailing list >>> >>> >>> >>> -- >>> Rowan Seymour >>> tel: +250 783835665 >>> http://twitter.com/rowanseymour >>> >>> >>> >>> -- >>> Rowan Seymour >>> tel: +250 783835665 >>> http://twitter.com/rowanseymour >>> >>> ________________________________ >>> >>> Click here to unsubscribe from OpenMRS Developers' mailing list >>> >>> ________________________________ >>> >>> Click here to unsubscribe from OpenMRS Developers' mailing list >>> >>> >>> >>> -- >>> Rowan Seymour >>> tel: +250 783835665 >>> http://twitter.com/rowanseymour >>> >>> ________________________________ >>> >>> Click here to unsubscribe from OpenMRS Developers' mailing list >>> >>> ________________________________ >>> >>> Click here to unsubscribe from OpenMRS Developers' mailing list >>> >>> >>> >>> ________________________________ >>> >>> Click here to unsubscribe from OpenMRS Developers' mailing list >>> >>> >>> >>> -- >>> Rowan Seymour >>> tel: +250 783835665 >>> http://twitter.com/rowanseymour >>> >>> >>> >>> -- >>> Rowan Seymour >>> tel: +250 783835665 >>> http://twitter.com/rowanseymour >>> >>> ________________________________ >>> >>> Click here to unsubscribe from OpenMRS Developers' mailing list >>> >>> >>> >>> ________________________________ >>> >>> Click here to unsubscribe from OpenMRS Developers' mailing list >>> >>> >>> >>> -- >>> Rowan Seymour >>> tel: +250 783835665 >>> http://twitter.com/rowanseymour >>> >>> >>> >>> -- >>> Rowan Seymour >>> tel: +250 783835665 >>> http://twitter.com/rowanseymour >>> >>> ________________________________ >>> >>> Click here to unsubscribe from OpenMRS Developers' mailing list >>> >>> ________________________________ >>> Click here to unsubscribe from OpenMRS Developers' mailing list >> >> >> -- >> Rowan Seymour >> tel: +250 783835665 >> http://twitter.com/rowanseymour >> > > > > -- > Rowan Seymour > tel: +250 783835665 > http://twitter.com/rowanseymour > > ________________________________ > Click here to unsubscribe from OpenMRS Developers' mailing list -- Thanks, Nyoman Ribeka _________________________________________ 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]
