Schema merge requestshttps://community.opengroup.org/osdu/platform/system/schema-service/-/merge_requests2022-11-18T23:55:19Zhttps://community.opengroup.org/osdu/platform/system/schema-service/-/merge_requests/408update buildspec2022-11-18T23:55:19ZMorris Estepaupdate buildspecupdate buildspecupdate buildspecM15 - Release 0.18Morris EstepaMorris Estepahttps://community.opengroup.org/osdu/platform/system/schema-service/-/merge_requests/404Cherry-pick 'M14 patch schema repo SHA 9d2306c4db8274b34910d4856d8f8a7ef296de...2022-10-17T16:42:44ZDavid Diederichd.diederich@opengroup.orgCherry-pick 'M14 patch schema repo SHA 9d2306c4db8274b34910d4856d8f8a7ef296de1b (2022-10-12) tag v0.17.1' into release/0.17**Original MR**: !403
### This MR is a Cherry Pick into a Release Branch.
After the release branch is first created, any subsequent changes use this process to update the release (often resulting in a new patch tag) without incorporati...**Original MR**: !403
### This MR is a Cherry Pick into a Release Branch.
After the release branch is first created, any subsequent changes use this process to update the release (often resulting in a new patch tag) without incorporating all changes in the default branch.
These MRs must be approved by the PMC before they are merged, since they alter the scope of the release.
To see more details about the change itself, look at the Original MR listed above.
#### Skipped Pipeline
Normally, pipelines are not executed on the cherry pick branch/MR prior to merging.
This optimization is accepted because the code was tested when it merged into the default branch, and will be tested again in the release branch prior to tagging.
However, if anybody feels that the MR requires further scrutiny -- whether because it had conflicts in the cherry-picking, it interfaces with some drastically altered logic between the branches, or any other reason -- we can run the pipeline here prior to merging.
#### If There's Reason to Run a Pipeline
If you want to see a pipeline result before this merges, first add a comment explaining why you'd like to see the pipeline results so the PMC and others know your thinking.
Then, mark the MR as a Draft MR (using the vertical ellipsis above, choose 'Mark as Draft').
This prevents the MR from being approved & merged accidentally by a busy release coordinator who didn't see your comment.
Finally, if you are a maintainer on the project, launch a pipeline on this branch.
Since this branch is a protected branch and the MR has ~no-detached-pipeline set, all integration tests will run and there's no need for any `trusted-*` branches.
[Launch a Pipeline for this Branch](https://community.opengroup.org/osdu/platform/system/schema-service/-/pipelines/new?ref=cherry-pick-for-403)M14 - Release 0.17David Diederichd.diederich@opengroup.orgDavid Diederichd.diederich@opengroup.orghttps://community.opengroup.org/osdu/platform/system/schema-service/-/merge_requests/402Cherry-pick 'Merge ibm helm' into release/0.172022-10-12T03:48:19ZDavid Diederichd.diederich@opengroup.orgCherry-pick 'Merge ibm helm' into release/0.17**Original MR**: !398
### This MR is a Cherry Pick into a Release Branch.
After the release branch is first created, any subsequent changes use this process to update the release (often resulting in a new patch tag) without incorporati...**Original MR**: !398
### This MR is a Cherry Pick into a Release Branch.
After the release branch is first created, any subsequent changes use this process to update the release (often resulting in a new patch tag) without incorporating all changes in the default branch.
These MRs must be approved by the PMC before they are merged, since they alter the scope of the release.
To see more details about the change itself, look at the Original MR listed above.
#### Skipped Pipeline
Normally, pipelines are not executed on the cherry pick branch/MR prior to merging.
This optimization is accepted because the code was tested when it merged into the default branch, and will be tested again in the release branch prior to tagging.
However, if anybody feels that the MR requires further scrutiny -- whether because it had conflicts in the cherry-picking, it interfaces with some drastically altered logic between the branches, or any other reason -- we can run the pipeline here prior to merging.
#### If There's Reason to Run a Pipeline
If you want to see a pipeline result before this merges, first add a comment explaining why you'd like to see the pipeline results so the PMC and others know your thinking.
Then, mark the MR as a Draft MR (using the vertical ellipsis above, choose 'Mark as Draft').
This prevents the MR from being approved & merged accidentally by a busy release coordinator who didn't see your comment.
Finally, if you are a maintainer on the project, launch a pipeline on this branch.
Since this branch is a protected branch and the MR has ~no-detached-pipeline set, all integration tests will run and there's no need for any `trusted-*` branches.
[Launch a Pipeline for this Branch](https://community.opengroup.org/osdu/platform/system/schema-service/-/pipelines/new?ref=cherry-pick-for-398)M14 - Release 0.17David Diederichd.diederich@opengroup.orgDavid Diederichd.diederich@opengroup.orghttps://community.opengroup.org/osdu/platform/system/schema-service/-/merge_requests/398Merge ibm helm2022-10-10T18:03:52ZManish SinghMerge ibm helmMerge ibm helm to masterMerge ibm helm to masterM14 - Release 0.17Anuj GuptaShrikant GargAnuj Guptahttps://community.opengroup.org/osdu/platform/system/schema-service/-/merge_requests/401Cherry-pick 'M14 snapshot schema repo SHA 1076d1347c3c1903dc09c01c69db5ce8eaf...2022-10-10T05:54:34ZDavid Diederichd.diederich@opengroup.orgCherry-pick 'M14 snapshot schema repo SHA 1076d1347c3c1903dc09c01c69db5ce8eafd5ba3 (2022-09-23)' into release/0.17**Original MR**: !387
### This MR is a Cherry Pick into a Release Branch.
After the release branch is first created, any subsequent changes use this process to update the release (often resulting in a new patch tag) without incorporati...**Original MR**: !387
### This MR is a Cherry Pick into a Release Branch.
After the release branch is first created, any subsequent changes use this process to update the release (often resulting in a new patch tag) without incorporating all changes in the default branch.
These MRs must be approved by the PMC before they are merged, since they alter the scope of the release.
To see more details about the change itself, look at the Original MR listed above.
#### Skipped Pipeline
Normally, pipelines are not executed on the cherry pick branch/MR prior to merging.
This optimization is accepted because the code was tested when it merged into the default branch, and will be tested again in the release branch prior to tagging.
However, if anybody feels that the MR requires further scrutiny -- whether because it had conflicts in the cherry-picking, it interfaces with some drastically altered logic between the branches, or any other reason -- we can run the pipeline here prior to merging.
#### If There's Reason to Run a Pipeline
If you want to see a pipeline result before this merges, first add a comment explaining why you'd like to see the pipeline results so the PMC and others know your thinking.
Then, mark the MR as a Draft MR (using the vertical ellipsis above, choose 'Mark as Draft').
This prevents the MR from being approved & merged accidentally by a busy release coordinator who didn't see your comment.
Finally, if you are a maintainer on the project, launch a pipeline on this branch.
Since this branch is a protected branch and the MR has ~no-detached-pipeline set, all integration tests will run and there's no need for any `trusted-*` branches.
[Launch a Pipeline for this Branch](https://community.opengroup.org/osdu/platform/system/schema-service/-/pipelines/new?ref=cherry-pick-for-387)M14 - Release 0.17David Diederichd.diederich@opengroup.orgDavid Diederichd.diederich@opengroup.orghttps://community.opengroup.org/osdu/platform/system/schema-service/-/merge_requests/387M14 snapshot schema repo SHA 1076d1347c3c1903dc09c01c69db5ce8eafd5ba3 (2022-0...2022-10-09T21:52:26ZThomas Gehrmann [slb]M14 snapshot schema repo SHA 1076d1347c3c1903dc09c01c69db5ce8eafd5ba3 (2022-09-23)Changes, additions as explained in the ChangeReport https://gitlab.opengroup.org/osdu/subcommittees/data-def/work-products/schema/-/blob/master/E-R/ChangeReport.md#snapshot-2022-07-22-towards-m14
Schema scope is PUBLISHED (=read-only) ex...Changes, additions as explained in the ChangeReport https://gitlab.opengroup.org/osdu/subcommittees/data-def/work-products/schema/-/blob/master/E-R/ChangeReport.md#snapshot-2022-07-22-towards-m14
Schema scope is PUBLISHED (=read-only) except for two experimental 'placeholders' Reservoir and ReservoirSegment.
Closes #113M14 - Release 0.17Thomas Gehrmann [slb]Thomas Gehrmann [slb]https://community.opengroup.org/osdu/platform/system/schema-service/-/merge_requests/400Cherry-pick 'Remove SNAPSHOT dependencies' into release/0.172022-10-09T02:14:34ZDavid Diederichd.diederich@opengroup.orgCherry-pick 'Remove SNAPSHOT dependencies' into release/0.17**Original MR**: !397
### This MR is a Cherry Pick into a Release Branch.
After the release branch is first created, any subsequent changes use this process to update the release (often resulting in a new patch tag) without incorporati...**Original MR**: !397
### This MR is a Cherry Pick into a Release Branch.
After the release branch is first created, any subsequent changes use this process to update the release (often resulting in a new patch tag) without incorporating all changes in the default branch.
These MRs must be approved by the PMC before they are merged, since they alter the scope of the release.
To see more details about the change itself, look at the Original MR listed above.
#### Skipped Pipeline
Normally, pipelines are not executed on the cherry pick branch/MR prior to merging.
This optimization is accepted because the code was tested when it merged into the default branch, and will be tested again in the release branch prior to tagging.
However, if anybody feels that the MR requires further scrutiny -- whether because it had conflicts in the cherry-picking, it interfaces with some drastically altered logic between the branches, or any other reason -- we can run the pipeline here prior to merging.
#### If There's Reason to Run a Pipeline
If you want to see a pipeline result before this merges, first add a comment explaining why you'd like to see the pipeline results so the PMC and others know your thinking.
Then, mark the MR as a Draft MR (using the vertical ellipsis above, choose 'Mark as Draft').
This prevents the MR from being approved & merged accidentally by a busy release coordinator who didn't see your comment.
Finally, if you are a maintainer on the project, launch a pipeline on this branch.
Since this branch is a protected branch and the MR has ~no-detached-pipeline set, all integration tests will run and there's no need for any `trusted-*` branches.
[Launch a Pipeline for this Branch](https://community.opengroup.org/osdu/platform/system/schema-service/-/pipelines/new?ref=cherry-pick-for-397)M14 - Release 0.17David Diederichd.diederich@opengroup.orgDavid Diederichd.diederich@opengroup.orghttps://community.opengroup.org/osdu/platform/system/schema-service/-/merge_requests/397Remove SNAPSHOT dependencies2022-10-07T06:46:15ZDavid Diederichd.diederich@opengroup.orgRemove SNAPSHOT dependenciesThis automated MR removes usage of `SNAPSHOT` versions in the first party library dependencies.
Since `SNAPSHOT` dependencies change frequently -- by their nature -- usage of them across projects is dangerous and should be avoided.
### ...This automated MR removes usage of `SNAPSHOT` versions in the first party library dependencies.
Since `SNAPSHOT` dependencies change frequently -- by their nature -- usage of them across projects is dangerous and should be avoided.
### Dependency Information Before the Upgrade
```
Branch: master
SHA: b74d46d040a389a3f29d3282abee66ec25c375c9
Maven: 0.18.0-SNAPSHOT
```
| Maven Dependencies | _Root_ | testing/ |
| ------------------------------------------------------- | --------------- | ---------------- |
| core-lib-azure | 0.14.0-rc2 | 0.6.1 |
| core-lib-gcp | 0.16.0 | |
| os-core-lib-aws | 0.18.0-SNAPSHOT | 0.13.0, 0.3.16 |
| obm | 0.16.0 | |
| oqm | 0.16.0 | |
| os-core-common | 0.13.0 | 0.13.0 |
| os-core-lib-ibm | 0.16.0-rc1 | 0.15.2, 0.7.0 |
| os-schema-core | 0.18.0-SNAPSHOT | 0.16.0-SNAPSHOT |
| osm | 0.16.0 | |
| (3rd Party) com.fasterxml.jackson.core.jackson-databind | 2.13.2.2 | 2.13.2.2, 2.11.3 |
| (3rd Party) net.minidev.json-smart | 2.4.7 | 2.3 |
| (3rd Party) org.apache.logging.log4j.log4j-api | 2.17.1 | 2.13.3 |
| (3rd Party) org.apache.logging.log4j.log4j-core | 2.17.1 | 2.13.3 |
| (3rd Party) org.apache.logging.log4j.log4j-jul | 2.17.1 | 2.13.3 |
| (3rd Party) org.apache.logging.log4j.log4j-slf4j-impl | 2.17.1 | 2.13.3 |
| (3rd Party) org.springframework.spring-webflux | 5.3.12 | |
| (3rd Party) org.springframework.spring-webmvc | 5.3.22 | 5.3.12 |
```
Warning: Found Vulnerable Spring WebFlux dependency (<5.2.20 || >=5.3.0 <5.3.18)
└─ _Root_
└─ org.opengroup.osdu.os-schema-azure == 0.18.0-SNAPSHOT
└─ com.azure.spring.azure-spring-boot-starter-active-directory == 3.4.0
└─ org.springframework.boot.spring-boot-starter-webflux == 2.4.12
└─ org.springframework.spring-webflux == 5.3.12
```
### Dependency Information After the Upgrade
```
Branch: remove-snapshots
SHA: 9df0237b9bc87a6815ca5a73627a3fcf8082ef8e
Maven: 0.18.0-SNAPSHOT
```
| Maven Dependencies | _Root_ | testing/ |
| ------------------------------------------------------- | ---------- | ---------------- |
| core-lib-azure | 0.14.0-rc2 | 0.6.1 |
| core-lib-gcp | 0.16.0 | |
| os-core-lib-aws | 0.17.0 | 0.13.0, 0.3.16 |
| obm | 0.16.0 | |
| oqm | 0.16.0 | |
| os-core-common | 0.13.0 | 0.13.0 |
| os-core-lib-ibm | 0.16.0-rc1 | 0.15.2, 0.7.0 |
| osm | 0.16.0 | |
| (3rd Party) com.fasterxml.jackson.core.jackson-databind | 2.13.2.2 | 2.13.2.2, 2.11.3 |
| (3rd Party) net.minidev.json-smart | 2.4.7 | 2.3 |
| (3rd Party) org.apache.logging.log4j.log4j-api | 2.17.1 | 2.13.3 |
| (3rd Party) org.apache.logging.log4j.log4j-core | 2.17.1 | 2.13.3 |
| (3rd Party) org.apache.logging.log4j.log4j-jul | 2.17.1 | 2.13.3 |
| (3rd Party) org.apache.logging.log4j.log4j-slf4j-impl | 2.17.1 | 2.13.3 |
| (3rd Party) org.springframework.spring-webflux | 5.3.12 | |
| (3rd Party) org.springframework.spring-webmvc | 5.3.22 | 5.3.22 |
```
Warning: Found Vulnerable Spring WebFlux dependency (<5.2.20 || >=5.3.0 <5.3.18)
└─ _Root_
└─ org.opengroup.osdu.os-schema-azure == 0.18.0-SNAPSHOT
└─ com.azure.spring.azure-spring-boot-starter-active-directory == 3.4.0
└─ org.springframework.boot.spring-boot-starter-webflux == 2.4.12
└─ org.springframework.spring-webflux == 5.3.12
```M14 - Release 0.17https://community.opengroup.org/osdu/platform/system/schema-service/-/merge_requests/399Cherry-pick 'Upgrade Tomcat' into release/0.172022-10-06T18:22:35ZDavid Diederichd.diederich@opengroup.orgCherry-pick 'Upgrade Tomcat' into release/0.17**Original MR**: !395
### This MR is a Cherry Pick into a Release Branch.
After the release branch is first created, any subsequent changes use this process to update the release (often resulting in a new patch tag) without incorporati...**Original MR**: !395
### This MR is a Cherry Pick into a Release Branch.
After the release branch is first created, any subsequent changes use this process to update the release (often resulting in a new patch tag) without incorporating all changes in the default branch.
These MRs must be approved by the PMC before they are merged, since they alter the scope of the release.
To see more details about the change itself, look at the Original MR listed above.
#### Skipped Pipeline
Normally, pipelines are not executed on the cherry pick branch/MR prior to merging.
This optimization is accepted because the code was tested when it merged into the default branch, and will be tested again in the release branch prior to tagging.
However, if anybody feels that the MR requires further scrutiny -- whether because it had conflicts in the cherry-picking, it interfaces with some drastically altered logic between the branches, or any other reason -- we can run the pipeline here prior to merging.
#### If There's Reason to Run a Pipeline
If you want to see a pipeline result before this merges, first add a comment explaining why you'd like to see the pipeline results so the PMC and others know your thinking.
Then, mark the MR as a Draft MR (using the vertical ellipsis above, choose 'Mark as Draft').
This prevents the MR from being approved & merged accidentally by a busy release coordinator who didn't see your comment.
Finally, if you are a maintainer on the project, launch a pipeline on this branch.
Since this branch is a protected branch and the MR has ~no-detached-pipeline set, all integration tests will run and there's no need for any `trusted-*` branches.
[Launch a Pipeline for this Branch](https://community.opengroup.org/osdu/platform/system/schema-service/-/pipelines/new?ref=cherry-pick-for-395)M14 - Release 0.17David Diederichd.diederich@opengroup.orgDavid Diederichd.diederich@opengroup.orghttps://community.opengroup.org/osdu/platform/system/schema-service/-/merge_requests/395Upgrade Tomcat2022-10-06T16:08:28ZXiangliang MengUpgrade Tomcatcommit f7804326
Author: David Meng <xlmeng@amazon.com>
Date: Wed Sep 28 2022 15:44:59 GMT-0400 (Eastern Daylight Time)
Upgrade Tomcatcommit f7804326
Author: David Meng <xlmeng@amazon.com>
Date: Wed Sep 28 2022 15:44:59 GMT-0400 (Eastern Daylight Time)
Upgrade TomcatM14 - Release 0.17Xiangliang MengXiangliang Menghttps://community.opengroup.org/osdu/platform/system/schema-service/-/merge_requests/393Update FOSSA NOTICE2022-10-02T21:31:55ZDavid Diederichd.diederich@opengroup.orgUpdate FOSSA NOTICEThis MR updates the attribution file for the project (also known as the `NOTICE` file).
It is important to keep this up to date to satisfy legal requirements of dependency licenses.
We use FOSSA as the tool to scan for and detect these ...This MR updates the attribution file for the project (also known as the `NOTICE` file).
It is important to keep this up to date to satisfy legal requirements of dependency licenses.
We use FOSSA as the tool to scan for and detect these changes.M14 - Release 0.17https://community.opengroup.org/osdu/platform/system/schema-service/-/merge_requests/391AWS Using Helm to Deploy2022-10-01T00:24:11ZMarc Burnie [AWS]AWS Using Helm to DeployM14 - Release 0.17Marc Burnie [AWS]Marc Burnie [AWS]https://community.opengroup.org/osdu/platform/system/schema-service/-/merge_requests/389Checkov Findings and Gitlab Helm Chart Deploy Variables2022-09-28T18:58:13ZMarc Burnie [AWS]Checkov Findings and Gitlab Helm Chart Deploy VariablesM14 - Release 0.17Marc Burnie [AWS]Marc Burnie [AWS]https://community.opengroup.org/osdu/platform/system/schema-service/-/merge_requests/388fixing aws pipeline2022-09-26T12:21:40ZMarc Burnie [AWS]fixing aws pipelineM14 - Release 0.17Marc Burnie [AWS]Marc Burnie [AWS]https://community.opengroup.org/osdu/platform/system/schema-service/-/merge_requests/357Remove schema-reference from .fossa-yml modules2022-09-25T13:24:38ZDavid Diederichd.diederich@opengroup.orgRemove schema-reference from .fossa-yml modulesThe reference module was removed in !343, but the fossa configuration was missed. As a result, the
`fossa-analyze` steps were failing, unable to list dependencies in the non-existent project.The reference module was removed in !343, but the fossa configuration was missed. As a result, the
`fossa-analyze` steps were failing, unable to list dependencies in the non-existent project.M13 - Release 0.16David Diederichd.diederich@opengroup.orgDavid Diederichd.diederich@opengroup.orghttps://community.opengroup.org/osdu/platform/system/schema-service/-/merge_requests/385AWS Helm Build Update2022-09-20T22:20:22ZMarc Burnie [AWS]AWS Helm Build UpdateM14 - Release 0.17Marc Burnie [AWS]Marc Burnie [AWS]https://community.opengroup.org/osdu/platform/system/schema-service/-/merge_requests/376Adding AWS Helm Charts2022-09-20T01:22:14ZMarc Burnie [AWS]Adding AWS Helm ChartsM14 - Release 0.17Marc Burnie [AWS]Marc Burnie [AWS]https://community.opengroup.org/osdu/platform/system/schema-service/-/merge_requests/109Schema validation changes2022-09-16T09:02:44ZAbhishek Kumar (SLB)Schema validation changes**Schema Validation Changes**
There are new schema validations going to be performed everytime there is a create or update request. These changes are driven by below rules:
[SchemaChanges](https://gitlab.opengroup.org/osdu/subcommittee...**Schema Validation Changes**
There are new schema validations going to be performed everytime there is a create or update request. These changes are driven by below rules:
[SchemaChanges](https://gitlab.opengroup.org/osdu/subcommittees/data-def/work-products/schema/-/blob/master/_doc/SchemaChanges.md)
[[_TOC_]]
# Schema Changes
Schema modifications have to be done with great care as schemas can be
used to generate code and API specifications. Changes may or may not break
clients consuming the schemas.
The solution to this is the concept of [semantic versioning](https://semver.org).
General rules have been defined during the
[R3 cycle](R3-changes/SchemaCompositionAndVersioning.md) in this summary:
* _Given a version number `MAJOR.MINOR.PATCH`, increment the:_
* _`MAJOR` version when you make **incompatible schema** changes,_
* _`MINOR` version when you add functionality **or contents** in a backwards
compatible manner, and_
* _`PATCH` version when you make backwards compatible bug fixes **or documentation/decoration changes**._
# Schema Service
New schemas are registered with the Schema service. The Schema service checks
the incoming schema definition against the previous minor and/or patch version
should they exist.
## Permitted Changes for PATCH Version Increments
Changes to the values (text) of the following JSON tags:
1. `title`
1. `description`
1. `example`
1. `pattern`
1. `$id`
1. `$comment`
1. any JSON extension tag starting with `x-osdu`
## Permitted Changes for MINOR Version Increments
In addition to all permitted changes in PATCH versions, the following
actions are permitted:
1. adding properties to existing data and nested structures
1. adding object structures to
1. `allOf` arrays and
1. `oneOf` arrays.
Explicitly not permitted is changing
1. the list of `required` properties
1. the state of `additionalProperties`.
It is permitted to declare existing properties as deprecated, preferable with
instructions how to migrate from the previous to the next version. The documentation
will automatically mark properties with ~~strike-through~~ if the description starts
with `"DEPRECATED: "`.
## Permitted Changes for MAJOR Version Increments
Any changes are permitted, specifically
* removal of properties
* removal of structures in `allOf`, `oneOf`
* changing the list of `required` properties
* changing the state of `additionalProperties`.M7 - Release 0.10Abhishek Kumar (SLB)Abhishek Kumar (SLB)https://community.opengroup.org/osdu/platform/system/schema-service/-/merge_requests/142Schema ref validation changes2022-09-16T08:44:03ZAbhishek Kumar (SLB)Schema ref validation changesThis MR introduces validation rule for `$ref` fragments. Basically, if there are minor level changes in the schema then all the $ref components of that schema are allowed to have incremental changes in their $ref versioning (incremental ...This MR introduces validation rule for `$ref` fragments. Basically, if there are minor level changes in the schema then all the $ref components of that schema are allowed to have incremental changes in their $ref versioning (incremental change in minor and patch level versioning). In other words, the schemas pointed by $ref can also have all permissible changes that are allowed at the Minor level (for more details please refer here [https://community.opengroup.org/osdu/platform/system/schema-service/-/blob/master/docs/SchemaService-OSDU.md#schema-validation].
Likewise, at the Patch level, $ref values are permitted to have incremented patch version.
For more example, refere to the issue https://community.opengroup.org/osdu/platform/system/schema-service/-/issues/61
## Code refactor
![image](/uploads/9d8017340e5455def4ff3a2af4e009e8/image.png)
![image](/uploads/6da1920a8e1eef46726fd90a60bfe645/image.png)
Along with the above state changes, there is code refactoring done to make components manageable and reusable. For example, earlier there were below classes:
- `schema-core/src/main/java/org/opengroup/osdu/schema/validation/SchemaMinorVersionValidator.java`
- `schema-core/src/main/java/org/opengroup/osdu/schema/validation/SchemaPatchVersionValidator.java`
which now, has evolved into different Handlers depending upon the kind of tags or operations they validate:
* AdditionalPropertiesHandler
* RemoveOperationHandler
* RequiredAttributeHandler
* TypeOperationHandler
* CompositionPropertiesHandler
* ReferenceAttributeHandler
## Testing
There are comprehensive set of Unit and IT test cases added/updated. To have a good test coverage, we have included several JSON files at below locations:
- https://community.opengroup.org/osdu/platform/system/schema-service/-/tree/schema-ref-validation/schema-core/src/test/resources/schema_compare [61 files]
- https://community.opengroup.org/osdu/platform/system/schema-service/-/tree/master/testing/schema-test-core/src/test/resources/input_payloads [88 Files]M10 - Release 0.13Abhishek Kumar (SLB)Abhishek Kumar (SLB)https://community.opengroup.org/osdu/platform/system/schema-service/-/merge_requests/144Added service version endpoint (GONRG-2938)2022-09-16T08:43:24ZAnastasiia GelmutAdded service version endpoint (GONRG-2938)## Type of change
- [ ] Bug Fix
- [x] Feature
osdu/platform/system/lib/core/os-core-common#47
## Does this introduce a change in the core logic?
- [YES]
## Does this introduce a change in the cloud provider implementation, if so whic...## Type of change
- [ ] Bug Fix
- [x] Feature
osdu/platform/system/lib/core/os-core-common#47
## Does this introduce a change in the core logic?
- [YES]
## Does this introduce a change in the cloud provider implementation, if so which cloud?
- [x] AWS
- [x] Azure
- [x] GCP
- [x] IBM
## Does this introduce a breaking change?
- [YES]
## What is the current behavior?
Provides info about maven build and gitM8 - Release 0.11Riabokon Stanislav(EPAM)[GCP]Rostislav Dublin (EPAM)Riabokon Stanislav(EPAM)[GCP]