For some reason when I run a build of the ref app from Daniel’s fork, I get the error as seen here, could this be because MDS hasn’t been set to require the hibernate compatibility module in the config.xml file which would make the offending class invisible to the module’s classloader?
@wyclif is that when you simply run mvn clean install?
I get the error when i try to run the ref app
I’m unable to reproduce the log out issue when i ran the build of the distro from @dkayiwa 's fork, Strange!
May be it was fixed. Are you able to reproduce it at http://uat01.openmrs.org:8080/openmrs/
@wyclif i have just made a commit to the metadatasharing module which should fix this.
Thanks @dkayiwa, the reference application and appui modules also fail to run against 2.0, issue being they reference deprecated methods or fields that were removed in 2.0, I will go ahead and fix them. I will test again and see, for now I can still reproduce the logout issue on uat server but not locally.
Just so you know, Burke and I had a discussion and noticed we can do some things better, there are 2 possible ways we can handle versioning of the platform and modules so that different versions are packaged for different CI plans. Below are the options, you can suggest more if you have any.
-
Creating a branch in the ref app distro project that builds against Platform 2.0.0-SNAPSHOT and the module versions will be snapshots too of the updated code that runs against 2.0, that way each CI plan can be pointed to a different branch based on the server to be deployed to, this implies we won’t need to point to someone’s fork. This also has the advantage that the code resides in the openmrs space and not a dev’s.
-
Alternatively we can replace the platform and module versions in the distro’s pom with maven place holders and use something like the maven properties plugin to set the appropriate versions based on the server one intends to deploy to. The property values (versions) can be read from an external file which can be passed to maven as an argument.
I’m more inclined towards the first option because in case something else comes up in the future that needs to be changed based on the server we are deploying to or some environmental factors, we can always have different values for different branches, and we can version control things too since everything would be in git
What do you guys think?
The first option looks good!
I managed to reproduce the logout issue locally, it was only happening in tomcat and most likely any standalone servlet container which is the cause for the uat server. I was running it in jetty so the class loading issue that was cause wasn’t arising, I’ve fixed as part of RA-1158