GSoC 2020 : Upgrade Platform Core Libraries Project

Tags: #<Tag:0x00007f0f22e37000> #<Tag:0x00007f0f22e36e48> #<Tag:0x00007f0f22e36ce0>

thanks @ibacher If I well understood, there is no possibility for webservices.rest 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? https://issues.openmrs.org/browse/FM-280 and https://issues.openmrs.org/browse/OWA-99 .

thanks @dkayiwa

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

2 Likes

th

thank you , can i work on this one
https://issues.openmrs.org/browse/OWA-99 ?

thanks @dkayiwa

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

2 Likes

@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

2 Likes

@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 .

2 Likes

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

<dependency>
	<groupId>org.openmrs.test</groupId>
	<artifactId>openmrs-test</artifactId>
	<type>pom</type>
	<version>${openmrs.version.1.10}</version>
</dependency>

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

2 Likes

and this line too from https://github.com/openmrs/openmrs-module-webservices.rest/blob/1b534e9b84272eeabe1357da5c3ca8ef4da8d5cb/pom.xml#L169 to https://github.com/openmrs/openmrs-module-webservices.rest/blob/1b534e9b84272eeabe1357da5c3ca8ef4da8d5cb/pom.xml#L187

1 Like

Sure , thats it

2 Likes

thanks @mozzy

2 Likes

Ensure all the Test libraries defined here in the OpenMRS core ,are not redefined in the Rest module Parent and Child POMs.

for example , you would also remove the depencies defined in the Child Poms like here in the child POM of sub-module 2.4 of the Rest Module

1 Like

@mozzy what about this https://issues.openmrs.org/browse/RESTWS-781 ?