Agenda for this Monday (24 January): Making decisions on OpenMRS Packaging conventions
We’ll review our Draft schema for OpenMRS Packages and work through some of the decision points. For example:
- What types of assets can be in a package?
- What string format convention do we use when referring to an asset (ESM, omod, metadata, etc.)?
- Which versioning format do we use?
- How should local assets (whether part of a package or downloaded during a build process) be organized?
When: Monday at 3pm UTC / 7am PST / 10am EST / 4pm CEST / 6pm EAT / 8:30pm IST
/cc @ibacher @mksd @eudson @mayanja @mseaton @mogoodrich @bistenes @jdick @ssmusoke @grace @raff & please CC others you think would be able to help us in creating initial conventions for packaging.
I have read through the document and have the following thoughts on approach
OpenMRS is a Java based platform and backend, so we need to stick with the Java based tools for building and packaging, in this case Maven - there are plugins for integrating with NPM
The front end technologies are going to change every 2-3 years, yet the backend is not going to change (now there is a push towards npm-less front end development) back to our good old days of copying a JS library into your assets
Leverage OpenMRS SDK to build and pull everything together, the backend omods and the front end-packaging - again delegating to maven then npm for front end assets
I know there is a push among the front end driven teams to move away from Maven and try something new, however given #2 above its imperative to stick to the backend tools and provide front-end extensions
IMO keep the omods and pull in the esms just like OWAs about 3-4 years ago
Quote: The more things change, the more they remain the same