Makes sense… I’ll try to slot him some time to do this the beginning of next week. @darius any thoughts in particular? Reason not to take this approach?
We originally took this approach of importing the distro pom to get its dependency versions so that we could more easily keep dependencies in sync across multiple reference application modules.
At this point it seems like the downsides are big enough that we should scrap it.
Another approach could be to keep collecting dependencies into a single place, but do this on a new pom-only repo that is then also imported by the reference application, so we remove the circular dependency problem.
-Darius (by phone)
@darius does it make sense for to try modifying the coreapps build as I mentioned above? If so, would it be better to wait until the release is out?
Mark
Per today’s PM call we decided that yes you should try this (and we will start UAT for refapp 2.5 in parallel).
-Darius (by phone)
Sound good…
One thing I will need to do it set up automatic commits, like we are doing with Transifex… I was just going to look at the Transifex plan to see how it was set up there. But does anyone know where the “release-scripts/update-and-commit-translations.sh” script used in the Transifex build is stored so that I can take a look at it?
Thanks, Mark
See https://github.com/openmrs/openmrs-contrib-bamboo
Do we strictly need to have automatic commits to use the latest released version?
Hmm… I think the “LATEST” option has been dropped in maven. I think we could technically update the versions and build against them using the versions plugin without actually committing the changes the plugin made–but would we want this?
Mark
Sorry, I was unclear.
I mean: why do we need to update automatically at all? Is it not okay to let each module keep requiring an older version of the others until a change is actually required, and someone does this manually?
It may not strictly be necessary–but I thought one of the main reasons we set up the reference app distro pom was because it was becoming a pain to have to upgrade a version number across numerous modules when a module was released.
This was the main idea behind the approach I mentioned earlier in the thread, though–was there confusion then on the PM call about what I was going to try out? What was the agreement?
Mark
On the PM call we just talked about whether this should block the 2.5 release or not (and decided we want to get it in, but to do UAT in parallel).
I remember why we originally took this approach, but I imagine that today we have many fewer changes to core modules like appframework and uiframework than we did back then, so this will be a much smaller problem.
So my advice would be:
- get rid of import of the distro pom
- put in explicit xyzVersion properties and dependencies
- don’t automatically update these at this point
- though we could start doing this in the future if we find it would help.
(I’m about to go offline for quite a few hours of flights, so if you all choose to go with @mogoodrich’s original idea of automatically updating, that’s fine.)
This makes sense to me… I can do a demo of the automatically update versions functionality if we want it–I suspect we will discover that although the updates are less frequent than before we still may want to do this.
I will not put anymore work into the for now… as a heads up, when I started working on this I figured it would be straightforward to get rid of the distro pom and but in explicitVersions, but for some reason context-sensitive tests started to fail… don’t know if I missed a dependency somehow, but I played around with it for a half-hour or an hour or so and seemed to be going deeper into a rabbit hole… 
We may want to take the opportunity to clean things up and remove the “dependency management” section entirely.
Mark
@taremwatadeo please double check and update the module versions on the Wiki page, https://wiki.openmrs.org/display/RES/Reference+Application+2.5+Release+Issue+Tracking, which are different from those at http://uat02.openmrs.org:8080/openmrs/. So far I have seen:
-
EMR API is 1.17 yet 1.18 is required
-
FHIR module is not included
-
UI Commons is 2.0 yet 2.1 is required
1 Like
@taremwatadeo now that you have ssh access to mdsbuilder, are you proceeding smoothly? Or are you blocked on something?
@taremwatadeo can you join the openmrs IRC channel and ping me from there? Am logged in as dkayiwa https://wiki.openmrs.org/display/IRC/Home
@taremwatadeo did you succeed with loading CIEL on mdsbuilder? Or are you blocked on anything?
1 Like
I sourced the latest CIEL dictionary on mds builder when it was released (last week?)
Ellen