Week 6: Abundant Progress and Midterms!

MarvinMarvin
7 min read

📅 July 7 – July 13

What I Planned to Do

  • 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

What I Worked On

  • I continued my endeavor from last week, where I was migrating my plugin from the REST module to its own repository

  • I made a new repository where I transferred all the plugin files from the REST module, and I started making the required changes in the pom file due to dependency issues

  • I had to try different ways because calling all the dependencies which was readily available inside the REST module was tricky, and it took a lot of iterations, but it finally worked!

  • The plugin was installing correctly; I was able to log all the resource properties for its default and full representations as I did earlier

  • Now I had mentioned about a proof-of-concept where I tried to completely change my approach from disabling context and avoiding it for the duration of the plugin, to embracing the context by using the BaseContextSensitiveTest which provided the required application context at build time

  • This was not familiar to me, and there exist a lot of complexities and little to no documentation that I was aware of, so I manually went through each Test class to understand where I even start with this

  • Since I had a maven plugin and not a test class, it was tricky to even see where I would get to use and implement this context, but there came a real genius idea, compliments to the community as always

  • I got an idea that what if instead of trying to bring the context into the plugin, I use the plugin to invoke the test which has access to all of the context, and its outputs all required information and the plugin processes it

  • This took a lot of brainstorming, trial and errors and failed approaches to even come to this solution because I was really trying to dig deep into the root of the context implementation which took a lot of my time

  • Specially, when I was stuck researching, my mentor Herman Muhereza took out his time to understand where I got stuck, made a test class implementing this context in a test as a REST submodule and ran it successfully!

  • This was more helpful than anything and it really got me out of the confusion, as although the test class depended on the old Swagger implementation which was outdated, I was fully excited seeing exactly how to use the context class for a test

  • This felt great! I then got on creating a very basic mojo that did nothing except give structure, and a test that just extended the context class and tried to print hello world, seems simple enough right? Wrong

  • It resulted in so many dependency issues since it resided in a different module, and I had to start over again by adding one config after another based on the error that popped up

  • Eventually the test ran! I then moved onto trying to use this new freedom to make another test where I try to invoke the RestServices and see if I am able to invoke any of the resources and get a proper instantiation

  • And yes, it did! I was successful in calling context into a standalone repository and use it to invoke the resource classes and use that to invoke the getRepresentationDescription() method

  • I swiftly moved onto replicating my previous plugin work by making a test which does the same work of invoking the method and getting the Default and full representations

  • Here is where I introduce to a very useful method which completely made this process so much easier, the getResourceHandlers() method, which is something offered by the RestServices which smartly scans the class loader for classes with @Resource annotation which was active for this platform version, collect them and put them in a collection to be accessed later

  • This made my job so much easier, I went through each handler, checked if it had the annotation, and if it did, I invoked the method and printed the property count in a json file that the test outputs

  • This test worked wonderfully, it outputted the json file which had all the resource files, and their property counts accurately detailed, which meant such a big obstacle was solved right here!

  • With such a big accomplishment, I moved onto integrating this test file and the mojo to work together, such that if I invoked the plugin, it should run the test file and output the json file

  • This seemed straightforward but there was no way that I was able to mix them together whatever I did, the plugin couldn’t find my test class and it threw a NoClassFoundException

  • This took a lot of attempts, but eventually I stumbled on the concept of making a forked jvm instance where I run the test, get the output and go ahead with further operations if we need which works really well now

  • In this week’s platform call, I kept forward my progress and I got very appreciative responses which meant this project was coming to life right in front of me now

  • Now with midterm evaluations of GSoC approaching, I had to make a checkpoint to show my progress and have good testing and documentation

  • I then cleaned out all the comments, added logging properly, I was manually making the json with a stringbuilder so migrated it to a jackson objectmapper, removed demo outputs, cleaned out the pom file out of any unnecessary dependencies and pushed the changes to my repository

  • Now it is ready to be cloned and to be ran in any computer and it will run as expected!

Challenges Faced

  • We still have a challenge to be addressed, to make the plugin truly version aware

  • The plan was to have the plugin to be used openmrs-wide, where anyone who wishes to use this plugin in their module to configure it in their pom file, and this plugin would get their platform version, and create the appropriate documentation

  • But currently, it runs on platform version 2.4.6 and REST version 2.5.0 which is not ideal, but steady progress is being made and is the biggest priority of the project

  • Another concern was to decide whether to have this plugin generate only 1 openapi spec or multiple for all platform versions, which is planned to be converted into npm packages for frontend developers to have ease in using, this is a future goal but something to be kept in mind

  • Understanding the dependency issues by the various spring contexts is very complicated, but eventually cleared out most of them

What I Learned

  • How to use a JUnit test class to invoke context at build time, and integrate it with the plugin to meet our goals

  • Introduced to the Jackson ObjectMapper, which simplified the process of creating a json file and made it clean and presentable

Commits/PRs This Week

Plans for Next Week

  • Configure the plugin to be version-aware, and move away from the default platform version and truly be dynamic and robust

  • Move forward with addressing other parts of the openapi spec, such as search handlers and other types of API requests

Notes/Discussion Points

  • I’m really grateful for my mentors who take out their time and really guide me without any expectations or annoyance, Chi Bong and Herman were truly helpful to me, and I appreciate that

  • Thankful for the community members like Rafal, Daniel and Ian who gave me suggestions and great approaches that completely revolutionized this project to another level

Thank you!

0
Subscribe to my newsletter

Read articles from Marvin directly inside your inbox. Subscribe to the newsletter, and don't miss out.

JavaOpen SourcemavenBeginner Developersgsoc#gsoc2025

Written by

Marvin
Marvin

21 | cs sophomore @ SPIT Mumbai | GSoC 2025 Contributor @ OpenMRS | Backend Dev | Java, Python, Spring Boot, Maven