Rowan, Yes, I would say we can go ahead and do the Git migration today and sort out other remaining issues afterwards.
As for the Openmrs 1.8.x compatibility issue, I changed the logic 0.4 dependency to <scope>provided</scope> and this *seems* to fix the problem with 1.8.x... by setting the scope to provided you are telling maven not to include the logic-0.4.jar in the omod package, which was conflicting with the logic-0.5.jar installed in 1.8.x. (Basically, I believe that setting the scope=provided is roughly equivalent to putting a jar in lib-common instead of lib in the pre-maven world). Mark From: [email protected] [mailto:[email protected]] On Behalf Of Rowan Seymour Sent: Monday, November 07, 2011 4:10 AM To: [email protected] Subject: Re: [OPENMRS-DEV] FW: HTML form entry changes I've switched htmlformentry to depend on org.openmrs.module.logic 0.4 which has been put in maven now. The test-hibernate.cfg.xml file now looks like: <hibernate-configuration> <session-factory> ${hbmConfig} <!--<mapping resource="TokenRegistration.hbm.xml" />--> <mapping resource="LogicRuleToken.hbm.xml" /> </session-factory> </hibernate-configuration> So all the unit tests pass, but this module currently doesn't work completely with OpenMRS 1.8 because of the differences between Logic 0.4 and 0.5. Does this mean we need a "pre1.8-compatibility" branch? Can we do the git migration today and sort out these issues afterwards? Thanks On 4 November 2011 16:39, Darius Jazayeri <[email protected]<mailto:djazayeri%[email protected]>> wrote: To clarify, modules ought to have two application context xml files. Spring combines all those plus the core ones into a single ApplicationContext. -Darius On Fri, Nov 4, 2011 at 7:13 AM, Friedman, Roger (CDC/CGH/DGHA) (CTR) <[email protected]<mailto:[email protected]>> wrote: So what happens when a module has a dependency on another module, or when multiple modules are loaded? Do we end up with 3, 4, 5 application contexts? From: [email protected]<mailto:[email protected]> [mailto:[email protected]<mailto:[email protected]>] On Behalf Of Michael Seaton Sent: Friday, November 04, 2011 9:33 AM To: [email protected]<mailto:[email protected]> Subject: Re: [OPENMRS-DEV] FW: HTML form entry changes Hey Rowan, I think we should encourage (or require) 2 application context's per module. It is already supported (moduleApplicationContext.xml and webModuleApplicationContext.xml) - you can see how we did this in the reporting module here: http://svn.openmrs.org/openmrs-modules/reporting/trunk/metadata/ I would say yes about going ahead and checking in htmlformentry with those failing unit tests, as we work on getting the external dependencies sorted out for fixing them. Mike On 11/04/2011 04:17 AM, Rowan Seymour wrote: 1. So we'd have two application context's per module? One in the API for services etc and one in the OMOD for controllers etc? 2. Can someone put logic 0.4 into the OpenMRS maven repos 3. Can I check htmlformentry into SVN now that we're down to a mere 3 failing tests? On 3 November 2011 21:36, Darius Jazayeri <[email protected]<mailto:djazayeri%[email protected]>> wrote: +2. Ben, Matt, etc, is there a reason we did things the way we did? (I.e. did something force us to put things in the omod project that don't really belong there?) -Darius On Thu, Nov 3, 2011 at 12:15 PM, Burke Mamlin <[email protected]<mailto:[email protected]>> wrote: +1 On Thursday, November 3, 2011, Nyoman Ribeka <[email protected]<mailto:[email protected]>> wrote: > 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]<mailto:[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]<mailto:[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.ReflectiveMethodIn-- > Thanks, > > Nyoman Ribeka > > _________________________________________ > > To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to > [email protected]<mailto:[email protected]> with "SIGNOFF > openmrs-devel-l" in the body (not the subject) of your e-mail. > > [mailto:[email protected]<mailto:[email protected]>?body=SIGNOFF%20openmrs-devel-l] > > ________________________________ Click here to unsubscribe<mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l> from OpenMRS Developers' mailing list ________________________________ Click here to unsubscribe<mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l> from OpenMRS Developers' mailing list -- Rowan Seymour tel: +250 783835665<tel:%2B250%20783835665> http://twitter.com/rowanseymour ________________________________ Click here to unsubscribe<mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l> from OpenMRS Developers' mailing list ________________________________ Click here to unsubscribe<mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l> from OpenMRS Developers' mailing list ________________________________ Click here to unsubscribe<mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l> from OpenMRS Developers' mailing list ________________________________ Click here to unsubscribe<mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l> from OpenMRS Developers' mailing list -- Rowan Seymour tel: +250 783835665 http://twitter.com/rowanseymour ________________________________ Click here to unsubscribe<mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l> from OpenMRS Developers' mailing list _________________________________________ 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]
