Week 5: Version Chaos and Community Wisdom!

📅 June 28 – July 6

---

What I Planned to Do

• Merge the PR and start working on handling @RepHandler methods or search handlers

• Discuss and decide on what resource class versions are to be taken to generate the OpenAPI specifications for

• Implement the plugin module wide and debug any edge cases that do arise

---

What I Worked On

• Picking up from last week, the problem I was trying to solve was how are we going to handle the fact that there exist multiple platform versions, and how do we decide which file gets OpenAPI spec for which version

• There exists two paths as I had gotten:

  1. Make the plugin version-aware, i.e. get the version of core that is being used, and scan and parse all the resource handlers that are concerned with that particular version

  2. Create different json files for each omod file, store it and at runtime fetch the appropriate file that matches with the core version

• The ideal plan was to make it version aware to make it more flexible, and lightweight but it required multiple complexities that I had to research and try out

• Meanwhile a big PR was pushed into the main rest module branch that made openmrs-core 2.4.x the lowest supported version, and removed all previous omod directories and transferred the supported resource handlers into omod-2.4

• This was a massive change and it required me to realign my strategy w.r.t. the plugin, and I got to pull the changes in my local instance and spent time resolving all merge conflicts

• My plugin was working against omod-1.8 so I had to migrate it to omod-2.4 and resolved all errors

• One issue propped up, which was after pulling the changes and resolving my plugin issues, the module wasn’t building successfully when I ran mvn clean install or mvn clean package

• It owed to the fact that some of the test classes were failing, so I got noticing and tried to run only that test when it ran successfully but when it runs with the whole module it always failed

• I boiled it down to the fact that the context it had for its test environment was compromised by some other test that ran before it and I tried a few different approaches when I got the issue and solved it, and got the build running

• I pushed the bug fix as a PR and got working on some of the plugin functionalities when I decided I needed some expert opinions regarding further decisions

• I attended the first OpenMRS GSoC mentee meet, where I gave updates about the whole experience and I asked the relevant place to ask my queries and was guided accordingly which was very helpful

• I attended the following platform call and kept my current progress and asked for the opinion of the long time experts of OpenMRS, specifically Rafal Korytkowski, where I was suggested various changes and offered me various alternatives which they felt was suitable for my project

• I was asked why is my plugin so closely coupled with the REST module and was suggested to move my plugin in its own repository that OpenMRS would add in its collection and maintain it down the line

• I asked Rafal to jote down his guidance on the talk thread which he graciously agreed to, I’d really suggest you to give it a read so you understand the sheer complexity of it

• He suggested me instead of avoiding the context completely, I could make it so that I can extend the BaseContextSensitiveTest class which has extensive application context at build time which would make invoking and finding out resources much easier if it worked

• I spent the next days reading about the intricacies of it, then made a small PoC to test whether what he suggested was possible, and that’s where I finish my week

---

Challenges Faced

• Deciding how to process parsing the relevant resource classes, and whether making it version aware is necessary considering its complexity

• Understanding the maven surefire plugin and the BaseContext test suite was a completely new domain to me, and understanding everything there is to it is extremely time consuming and complex

---

What I Learned

• Learnt about how test class loading, and how to handle context to solve it from breaking the build

• Tried to understand the application context side of OpenMRS and how everything works that side of the module

---

Commits/PRs This Week

• PR Title: Initial implementation of OpenAPI Generator Maven Plugin with JavaParser integration

• Link: RESTWS-980: Initial implementation of OpenAPI Generator Maven Plugin with JavaParser integration by capernix · Pull Request #657 · openmrs/openmrs-module-webservices.rest

• Status: Draft

• PR Title: Error in TaskActionController when clean installing the REST module

• Link: RESTWS-984: Error in TaskActionController when clean installing the REST module by capernix · Pull Request #665 · openmrs/openmrs-module-webservices.rest

• Status: Open

---

Plans for Next Week

• Decide if using the application context is necessary or continue with my current maven plugin approach

• Handle the version-aware side of logic and make a PoC demonstrating that it works

• Brush up all my progress, document it properly and prepare for the midterm evaluation

---

Notes/Discussion Points

• I was very grateful and happy looking at the help I was getting from my mentors and community members who did all they can to accommodate my ideas and help me further

• Tip to self - Do not venture too deep into code without properly discussing alternatives, structure and logic of the whole plan

---

Thank you!