I'd like to begin by extending my apologies for the absence of recent blog posts.
In recent weeks, I had to devote some time preparing for exams, which caused a temporary break in my blog updates.
So here are the tickets I worked in the last few weeks.
This ticket was brought to my attention by my mentor, and as I delved into it, I discovered the following issue:
The OpenMRS SDK uses the project directory's path to determine whether two projects are identical. This is done to prevent the same project directory from being added twice as a watched project.
Here's the Project equals method responsible for this comparison.
However, this approach doesn't prevent users from adding the same module twice if they are located in different directories. For instance, if a user adds the "web services.rest" module from two different directories, the SDK treats them as separate watched projects. This can lead to issues when running the server.
I fixed this issue by implementing a check in the OpenMRS SDK to ensure that a server does not watch multiple modules of the same type.
PR: https://github.com/openmrs/openmrs-sdk/pull/250
I addressed some formatting errors in the pull request as suggested by my mentor, and these changes have been successfully merged.
This is a bug that was reported a few years ago. According to the ticket, when attempting to run a platform 2.3.3 server with OpenMRS SDK 4.2.0, Liquibase changeset errors occurred shortly after startup.
I tried to replicate this issue with both OpenMRS 4.2.0 and the latest SDK version, but no errors surfaced. This leads me to believe that the problem may have been an issue within the OpenMRS core that has since been resolved.
Given our inability to reproduce the error, we reached the decision to close this ticket.
The OpenMRS Java convention strongly advocates the use of slf4j for logging. In the OpenMRS SDK codebase, I identified several instances where System.out.println was being used for logging instead of the recommended slf4j.Logger.
In this pull request I replaced these occurrences with slf4j logging.
As previously discussed in my last blog post, I continued to work on this ticket. The objective here is to enhance the non-interactive usage of the SDK setup for all available options.
To implement this improvement, I utilized the Maven Help Plugin. Instead of relying on a help.yml file for documenting plugins, I employed the following command within the SDK:
mvn help:describe -DgroupId=org.openmrs.maven.plugins -DartifactId=openmrs-sdk-maven-plugin -Dversion=5.3.0-SNAPSHOT -Ddetail
I've created a pull request for this enhancement and am now awaiting its review.
One of the challenges we encountered while working with the SDK was its approach to cache management. Every time the SDK runs a NPM command, it creates a cache in the temporary directory. For instance, when building the OpenMRS O3 snapshot using the SDK, a cache folder of approximately 1.1 GB is generated.
This excessive use of storage space not only poses a problem for users with limited storage but also results in data-intensive operations.
In light of these issues, I collaborated with my mentors to find a solution. After considering various approaches, we settled on the following solution:
- Introduce an optional parameter in the setup-sdk plugin that allows users to enable 'reuseNodeCache.' This user preference will be stored in the sdk.properties file.
- During the execution of the npm build process, we will check if the 'reuseNodeCache' option is enabled. If it is, we will reuse the existing npm cache; otherwise, we will proceed to delete the npm cache.
I have created a pull request to implement this solution, which you can find here.
We recently had the OpenMRS GSOC showcase on September 19, 2023, and it was a truly exciting event. I thoroughly enjoyed the presentations from my fellow contributors.
I also had the opportunity to share my progress, which you can watch in the following presentation video: https://www.youtube.com/watch?v=Vn0cUZndCJM
That's all for this week. Thank you for taking the time to read about my progress.See you next week!