Wanted to inquire if – first of all – the source code should be moved to OpenMRS org, and if there’s a formal procedure for this or I should just go ahead and transfer the repo?
Great to read that your org is giving back this way. That’s the way to go!
Would it be possible to
- Expand on the README so that it actually describes what the modules intends to achieve, example here.
- Is there any wiki doc elsewhere? If not then let’s expand even more on 1.
- There’s still target folders in both /api and /omod, I also I think it’s a lot better to maintain one .gitignore file at the top level when possible. You can find plenty of sample configs around, such as here for instance.
- Better also to add a code formatter, look here for one and here for a sample use at compile time that you should adapt to your needs (you can add .js files for example which wasn’t relevant to our module).
I have taken one of our modules as an example, we also intend to transfer it to the community in the near future.
DHIS2 connector encoding error
1-3 are in our queue. We’ll provide detailed documentation. About the code formatting, I thought mvn takes care of it, doesn’t it?! I’m using Openmrs’s provided templates for Eclipse, so not sure where things went out of convention. I’ll take another look.
Not everybody will rely on Eclipse though, or will have the awareness to configure it to follow OpenMRS’ code guidelines, hence the idea to ensure that every build does format it. Of course you still have to ask every potential committer to at least run the Maven build before making a PR…
And no Maven will not format the code unless you configure ad-hoc plugins to do so (which is the kind of approach I provided in my point 4). There is not only one way to have the code auto-formatted upon building, other projects might take a different approach. We have found that the above works pretty flawlessly, I just don’t like the way it format XML files, so in general I skip those.
Thanks a bunch @mksd, I’ve followed your suggestions, the project now:
- Contains single gitignore file
- Has formatting plugin, which formats code on maven build according to OpenMRSFormatter.xml
- README file connects to the Wiki link for module documentation
Anything else you’d recommend before making the transfer?
Ok that’s great @owais.hussain, thanks for following the suggestions. I hope that you did find the outcome beneficial.
I see here that it depends on Core 2.x, meaning Java 8 is required which contradicts what’s written in the README. I would advise you to have a really neat README, that’s what people see first after all. Something that looks copy/pasted or autogenerated already diminishes the first impression, which is a pity because you did put some effort on the wiki page and that’s great.
I saw quickly that there was a number of unit tests. I don’t know whether there is enough unit testing or not. That’s important because from then on this module will become the community’s responsibility as well, even though I suspect that you will remain the main point of contact about it “for some time”.
It transpires through the wiki article but it is not that clear (especially to newcomers that might get attracted to it through its name) that the module is not Ref App compatible, UI-wise. You would want to make it clear as well in the wiki’s overview.
Thanks for the great work and for sharing it with the widest audience.
I did some finishing work, including unit test coverage which on Eclipse’s sonar plugin shows 81% for API and about 30% for OMOD; we will keep adding more tests in this, but the API has been tested satisfactorily. Wiki page has also been created. I’ll be migrating the repository to OpenMRS today and then look forward to push to Add-ons directory.
Thanks all for the contribution and support. I hope the community benefits from this effort.