Week 10: The quest for module independence!

📅 August 04 – August 10

---

What I Planned to Do

• To fix the introspector bug and come up with an enhanced and watertight version with robust property introspection

• To move forward with generating openAPI specs for the search handlers and RepHandlers

---

What I Worked On

• Last week I was stuck on a couple errors where some resource handlers were not getting accurate property introspection, and I was implementing an enhanced service implementation

• I continued that work this week starting with getting the introspector files inside the REST module again for ease of testing and controller necessity

• The problem was that the introspector seemed to miss some resources which had obscure delegate types in the generic, like UserResource2_2 had UserAndPassword1_8 instead of user which made it skip over some properties

• Furthermore, it wasn’t always including all the properties from getRepresentationDescription() skipping a lot of the properties which was a direct result of us solely depending on reflection and not specifically accessing the method

• I made a change of storing the properties I get when I invoke the method from different rep types in the test class, and printing the unique ones so we always have all the properties from its from

• I then experimented with other ways to fallback for the introspection logic and compared the output to the original which was more promising

• I took out the new logic, implemented in the schema introspector and I witnessed more robust openapi spec than before

• After I was done with this issue, I got on a meet with my mentor to discuss further steps and verification of the code I wrote

• We discussed and came to the conclusion that there are a lot of goals we have remaining but there are a couple which command the highest priority

• It was essential the module could scan and introspect on any module other than REST as well, like the queue’s module or any custom-made modules that users might have

• Currently we call the REST dependency inside the plugin and run the plugin that way but this was hardcoded, and we needed to move away from this position

• Other than this one other goal which is not as important but still would be a good addition is refactoring the search handler types for easy documentation and inference

• This could be done by anyone else as the work is known but it just takes time so this is not the biggest priority unlike the module averse plugin goal which had to have a novel solution

• I was advised that I can start with a small maven plugin and try to make it work in the way I want it, like hosting it inside the pom file and it being able to read the module name and package name as well

• I moved forward with this idea and implemented a basic hello world mojo which printed hello world if applied in the omod pom file

• After experimenting with that basic logic, I moved onto module discovery which displayed all the relevant module info as we needed it

• I wrote and successfully was able to make it work after some efforts and I tried to migrate that logic to my plugin with test context and openmrs dependencies, which I’ll further investigate next week

---

Challenges Faced

• To check and debug the issue of incorrect schema introspection and successfully identifying the root cause and coming up with a good solution

• My biggest challenge yet has been converting my maven plugin which calls in it’s dependencies to make it module averse and make it into a pom file declaration type system

---

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

• Check out my plugin repository: https://github.com/capernix/openmrs-maven-plugin-openapi

• My Demo Video: https://youtu.be/SQ_ksJfMjsA?si=AiG1momcw8HO-HIC

---

Plans for Next Week

• Move the logic from my mini mojo to my comprehensive openapi maven plugin, and debug and resolve any errors that arise

• To come up with the final steps of aggregating the openapi specs and displaying accurate documentation

---

Notes/Discussion Points

• The logic of making the plugin module averse is not straightforward and needs community engagement so I’ll be sure to interact and raise my issue in the next platform meet

---

Thank you!