GSoC 2020 : Upgrade Platform Core Libraries Project

Community GSoC
, ,
63

yes, thanks @sharif

64

I am trying to update junit 4.11 to 4.13. it gave me this error:

Screenshot from 2020-06-25 07-37-37
Screenshot from 2020-06-25 07-37-371214Ɨ529 105 KB
to correct it i added this couple of dependencis:

      <dependency>
		<groupId>org.powermock</groupId>
		<artifactId>powermock-api-mockito2</artifactId>
		<version>2.0.7</version>
		<scope>test</scope>
	</dependency>

	<dependency>
		<groupId>org.powermock</groupId>
		<artifactId>powermock-module-junit4</artifactId>
		<version>2.0.7</version>
		<scope>test</scope>
	</dependency>

and its gave me this error:powermock - Pastebin.com.

To solve it I downgrade the version of powermock to 1.6.1. how i can solve the problem without downgrade the powermock version. thanks @ibacher @mozzy @teleivo

65

Did you try downgrading to a stable version of powermock to 2.0.0 and see the reaction?

1 Like
66

Yes but It didnā€™t work, the only version that is working is 1.6.1

67

Let us back up for a second and consider whether or not this ticket is actually a good idea. The webservices.rest module is pretty unique in that it supports a large number of OpenMRS versions with version-specific code. That means that each submodule ends up depending on a different version of OpenMRS core than any other submodule.

The upshot of this is that the unit tests for each submodule of webservices.rest depend on a specific version of OpenMRS with their own versions of Mockito, Hamcrest, JUnit, PowerMock, etc. So I think weā€™re fundamentally going to be doing the wrong thing by trying to keep a single version of the test framework that works across all submodules. Instead, what we need to do is to ensure that every submodule depends on the right version of the test classes provided by the relevant version of OpenMRS. So, for instance, the omod-1.10 version should depend on the version of the test modules bundled with OpenMRS 1.10.

That sounds like a lot of work, but itā€™s actually already done for us with POM entries like this (taken from the pom.xml file for omod-1.10:

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

What this does is import the dependencies and version information from the 1.10.4 version of the org.openmrs.test.openmrs-test artifact, which are defined here. This implicitly includes the versions of JUnit and Mockito that were installed for OpenMRS 1.10.4, as defined in the main pom here. So, by relying solely on importing these dependencies from a specific version of OpenMRS, we ensure each module has a consistent set of test dependencies that donā€™t interfere with one another. In this particular case, it means that omod-1.10 will be tested with JUnit 4.11 and PowerMock 1.5.

So, rather than try to find a magical combination of these dependencies that will work for all versions of OpenMRS (which is unlikely to be found), we should simply switch things so that the webservices.rest module does not specify any versions of JUnit, Hamcrest, Mockito, etc. In other words, I think that instead of upgrading these libraries, we should instead remove the definitions for the JUnit, Hamcrest and Mockito artifacts from the main pom.xml and remove the lines which explicitly add these dependencies to every submodule of webservices.rest.

On my local machine, when I delete lines 108-132 and 169-187, everything builds successfully. This does mean that only tests located in the omod-2.4 subdirectory will use the newest testing framework, but I actually think thatā€™s the desired behaviour.

I hope what Iā€™ve said above is clear. Iā€™m sorry for all the text.

2 Likes
68

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

69

thanks @ibacher

70

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:

<properties>
    <maven.compiler.source>8</maven.compiler.source>
    <maven.compiler.target>8</maven.compiler.target>
</properties>

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
71

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.

72

Thanks @ibacher for more of clarification

73

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

74

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

2 Likes
75

th

thank you , can i work on this one
[OWA-99] - OpenMRS Issues ?

thanks @dkayiwa

76

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

2 Likes
77

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

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

i didnā€™t get it well @mozzy .

80

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

81

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

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