Legal community implementation plus Pluggable Drivers

Description:

Link to story: https://gitlab.opengroup.org/osdu/pmc/community-implementation/-/issues/25
More details about the solution: https://community.opengroup.org/osdu/documentation/-/wikis/Pluggable-approach-for-Mappers-and-Drivers

As a part of the community implementation solution Legal-GC module was refactored to the Legal-Core-Plus module, in addition new pluggable approach for Drivers was used.

What is the current behavior?

• We do not have the core-plus module.
• Drivers not pluggable, all dependencies bounded during the compile step.

What is the new behavior?

• We have the core-plus module.
• Drivers are pluggable and could be attached to service during image build, not compile.

Key components of pluggable configuration:

1. Add spring boot loader to service dependencies to core-plus service pom.xml, in this MR this dependency was added to legal-core-plus pom.xml

    <dependency>
      <groupId>org.springframework.boot</groupId>
      <artifactId>spring-boot-loader</artifactId>
      <version>2.7.15</version>
    </dependency>

2. Update service configuration to use Properties launcher from spring boot loader as the main class, in the same legal-core-plus pom.xml:

      <plugin>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-maven-plugin</artifactId>
            ...
            <configuration>
              <classifier>spring-boot</classifier>
              <mainClass>
                org.springframework.boot.loader.PropertiesLauncher
              </mainClass>
            </configuration>
            ...

2. Download plugin artifacts(jar files) before building a Docker image or running it locally. The location could be any, the only requirement is to be accessible for running env or Docker image build:

    - mvn dependency:copy -DrepoUrl=$OSM_PACKAGE_REGISTRY_URL -Dartifact="org.opengroup.osdu:os-osm-postgres:$OSM_VERSION:jar:plugin" -Dtransitive=false -DoutputDirectory="./tmp"
    - mvn dependency:copy -DrepoUrl=$OBM_PACKAGE_REGISTRY_URL -Dartifact="org.opengroup.osdu:os-obm-minio:$OBM_VERSION:jar:plugin" -Dtransitive=false -DoutputDirectory="./tmp"
    - mvn dependency:copy -DrepoUrl=$OQM_PACKAGE_REGISRTY_URL -Dartifact="org.opengroup.osdu:os-oqm-rabbitmq:$OQM_VERSION:jar:plugin" -Dtransitive=false -DoutputDirectory="./tmp"

3. Copy plugin jars into the Docker image:

COPY tmp/os-oqm-rabbitmq-*.jar plugins/oqm-rabbitmq.jar
COPY tmp/os-obm-minio-*.jar plugins/osm-minio.jar
COPY tmp/os-osm-postgres-*.jar plugins/osm-postgres.jar

4. Bundle service with plugins using run args, point to the directory with plugins, and point to the original main class:

java ...
          ...
         -Dloader.path=plugins/ \
         -Dloader.main=org.opengroup.osdu.legal.LegalApplication \
         -jar /app/legal-${PROVIDER_NAME}.jar

5. Args could be provided as IDE configuration if running locally, it should be an absolute path then.

<option name="VM_PARAMETERS" value="-Dloader.path=/Users/projects/Legal/plugin-download-path... -Dloader.debug=true -Dloader.main=org.opengroup.osdu.legal.LegalApplication --add-opens java.base/java.lang=ALL-UNNAMED --add-opens java.base/java.lang.reflect=ALL-UNNAMED" />

How to test:

Via integration tests.

Changes include:

• Refactor (a non-breaking change that improves code maintainability).
• Bugfix (a non-breaking change that solves an issue).
• New feature (a non-breaking change that adds functionality).
• Breaking change (a change that is not backward-compatible and/or changes current functionality).

Changes in:

• Common code

Dev Checklist:

• Added Unit Tests, wherever applicable.
• Updated the Readme, if applicable.
• Existing Tests pass
• Verified functionality locally
• Self Reviewed my code for formatting and complex business logic.

Other comments:

Any comments to approvers here