Thank you for such detailed guidance! I’ll do the needful and start testing this approach
I wanted to clarify on a method that I currently use in my current plugin
In this file, line no 76
Collection<DelegatingResourceHandler<?>> handlers = restService.getResourceHandlers();
So how do these resource handlers get decided by openMRS? Are these files accurate? I now use the resource files found out through this, is this reliable enough that I can generate openapi spec based on this?
As before without context I was scanning each file present in the classloader by scanning for @Resource annotation and presence of getRepresentationDescription() method, but now I use the files returned by the aforementioned function.
Since I am unfamiliar with the workings of it I wanted to clarify if that is something that we can rely on to return accurate resource files and then generate openapi spec on it? Any clarification would be appreciated.
Hello everyone!
Following up because although the test class is working beautifully, I am running into some problems constantly
-
I am unable to run the test file in the plugin so I am not able to integrate the plugin and test for now
-
As this plugin exists in its own separate repository, I use REST module as a dependency where the test uses it to generate the output, but I envisioned it to be configured in the REST pom file and the test running there, so it could be run in any module that it is referenced it but I am unable to get past the spring context issues so would like any reference code or approach to improve this
Would love any feedback!
cc: @raff @dkayiwa @mherman22
Hey Everyone!
I’m nearing the end of the GSoC timeline and I’m happy to say there has been tremendous progress with respect to the modularity and portability of the plugin
We just add the plugin config in the concerned modules pom.xml file (like queues/omod or webservices.rest/omod-2.4), run the module with mvn clean process-classes and it generates an openapi.json file in the target/openapi directory of the module we ran the command on.
Currently this plugin exists solely in my GitHub repository, what are the steps to add it with the OpenMRS org and make it available in a way that we can add the configs in the REST and queues module without the build failing?
Can you start by sharing the repository url?
Sure @dkayiwa !
Hey everyone!
I’m happy to say my openapi plugin repo has officially been included under the OpenMRS organization!
I hope everyone gives it a try and point out any improvements that it needs
Repo link: openmrs/openmrs-contrib-openapi-maven-plugin
The next step that follows this is applying the plugin in the REST and queues module but I have to ensure something before I open a PR
Current priority:
In order to verify the openapi spec is upto the mark, I am working on implementing validation tests. Does anyone have any references or suggestions on how should I go ahead with this? For example how can I test endpoints like /patient which requires a patient uuid to get a response? Any advice would be appreciated
Are you looking for testing frameworks like REST-assured?
No I was using python scripts, I’ll give it a try and come back thank you!