GSoC 2020 : Upgrade Platform Core Libraries Project

Tags: #<Tag:0x00007f0f1cc56070> #<Tag:0x00007f0f1cc55f30> #<Tag:0x00007f0f1cc55da0>

thanks @ibacher , my main target is the java version , because i want to upgrade the java version of The ,that’s why i started with the dependencies. is it possible to do it ?

thanks @ibacher

Could you clarify a bit what you mean by this? I.e., are you hoping to be able to use 1.8 (or newer) features inside submodule or to actually build the whole module on, say Java 14?

The first of those is probably straightforward. I think it involves just adding:


To the java-8 profile.

The latter problem is much harder to solve, because we need to balance the need to continuing to support older versions of OpenMRS with the breaking changes that are rolled into Java 9. I’m not certain what the solution is there.

1 Like

thanks @ibacher If I well understood, there is no possibility for to support java 8, 11 or any new version at the same time.

Thanks @ibacher for more of clarification

please can you help me evaluate this tickets and the sub-tasks? and .

thanks @dkayiwa

Since we are replacing the FHIR module with FHIR2, i suggest that you do not waste your efforts on FM-280



thank you , can i work on this one ?

thanks @dkayiwa

That is why i made it ready for wodk :slight_smile:


@achilep Well done for the Beautiful work.

Now , for the moment , i would be in favour of keeping the Java Version for other Modules like FHIR ,WebREST at 8, as it may be too costly in terms of time and Resources (which may not be available at the moment) to keep the backward compatibily. Also given Modules like FHIR2 are just still WIP. We would first focuss on the other minor libraries


@achilep , regarding the JUNIT ugrade in Web Rest module, have you started trying out the alternative @ibacher suggested, ?? seems a better idea rather than explicitly defining the test-libraries Versions .


i didn’t get it well @mozzy .

@mozzy For the rest web, I’m a bit scared of the junit , because the junit version use for each sub-module depends on the version used for the core API.

@ibacher gave an alternative to Upgrading the test libraries in the WEb Rest module.

The idea is The Rest Module has different Sub-modules which depends on different Versions of Openmrs Core ,yet the different OpenMRS Core Versions also depend on different versions of a test Library.

So Instead of Explicitly defining a specific version of the test libraries we would simply depend directly on the test libraries provided by the openmrs core ,meaning each sub module of the Rest Services module will depend on a different test clases provoded by the coresponding OpenMRS core Version ,

example for sub module omod-1.10 of the Rest module


Just do that for the rest of the sub modules.

You can remove out all the the test library dependencies explicitly defined in the child poms of the Rest module

1 Like

simply depend on the libraries provided by the test submodule of the OpenMRS Core.

Remove out all the test depencies that have been directly and explicitly defined in the rest module

1 Like

thank you very much for clarification . For this :

should i work on FHIR2 ? or it is not yet the moment.

Example remove out al these lines

and replace that with a single dependece on the test sub module of the OpenMRS core,

In that way , the sub-module will simply inherit the test libraries/dependencies defined in the coresponding OpenMRS core Version

1 Like

FHIR2 is still Work in progress as per say , @ibacher could direct you best where necesarry


and this line too from to

1 Like

Sure , thats it