Although I didn't have much coding to show this week, I spent valuable time discussing the build-distro plugin implementation and planning the next steps with my mentors.
build-distro plugin
My mentor wanted to know why we couldn't use the current implementation of the build-distro plugin to deploy O3 docker configuration.
I have tried to deploy O3 configurations with the current implementation without any success. I decided to give it another try.
These are some of the differences I noticed.
- The distro file naming convention: In O3, the distro file is named "distro.properties" instead of "openmrs-distro.properties" as used in the old reference application.
- Packaging artifact differences: O3 distro package only contains a "zip" artifact, which differs from the previous implementation.
- Missing configuration files: Certain configuration files present in the old reference application, particularly in the "distro/configuration" directory, were not being copied for O3.
- Template-based Docker configurations: The SDK used template-based generation of Docker configurations for O2, but this approach is not applicable to O3.
- Directory structure disparities: There are differences in the directory structure between O2 and O3.
Considering the complexity and time involved in modifying the existing code to accommodate these differences, I concluded that cloning the reference application from GitHub is a more efficient and user-friendly approach for deploying O3 configurations.
Improve the build-distro and setup commands by allowing per-version customizations
Our next goal in the GSOC project is to enhance the build-distro and setup commands by enabling per-version customizations. We aim to automate the process of selecting the appropriate Java version (Java 8 or Java 11) based on the OpenMRS version being used.
To achieve this, we plan to take the following approach:
- Add Java 8 and 11 Docker files to the build-distro plugin's resources: We will include the relevant Docker files for Java 8 and Java 11 in the plugin's resources.
- Version-based selection: During the build process, the SDK will determine the OpenMRS version being used. For versions between 2.0 and 2.3 (inclusive), the SDK will default to generating Docker images based on Java 8. For versions 2.4 and newer, the SDK will use Java 11 as the base image for Docker images.
I am anticipating to complete this within this week. Thank you for following my progress, and I'll keep you updated on further developments. Thanks for reading.