Deployment - Refactor and separate the code base into two: Transformer and Provider
Goal: Meet structural prerequisites so OSDU's standardized pipelines for scanning, building, deploying have improved compatibility with GCZ.
Problem: GCZ repo currently houses two applications in Transformer (Java) and Provider (JavaScript), but OSDU Pipelines anticipate a repository to host a singular application at the root level. If you attempt to run the Maven build script from OSDU on our repository, it will be unsuccessful because our Java application is nested below the root.
Solution: Break repository in two
- Geospatial (the current repository): Remains host to the core GCZ docs, test assets, and gcz-transformer code. This repository would also remain the hub for any issues or discussions related to the GCZ effort.
- Provider: Becomes new host for gcz-provider. Includes documentation specifically pertaining to Provider, but also links relevant information back to Geospatial repository.
This will not affect the code itself, or any functionality of the GCZ services.
Note: Provider is wholly dependent on the Transformer, so these services should always be expected to run in tandem.
Benefits:
- Separate pipelines/branches per service
- Improved compatibility with standard-setup, scan, build pipelines from OSDU
- More familiar structure with clearer separation of concerns
Disadvantages:
- Issues that span both repositories will require twice the maintenance to close
- Increased onboarding complexity with two codebases
@chad @debasisc @divido @joelvromero - I will request approval from each CSP below, but in the meantime please reply below if any concerns come to mind that are not addressed above.