Unification of all supported Trust Framework versions under a single service #11
Conversation
### Added - introduce vavr.io library for neater code ### Changed - rename endpoint path to reflect API version (/api/22.04/selfdescription) - better error propagation from the Custodian to get more details on a error - update Spring Boot from 2.7.5 -> 2.7.6 - update springdoc-openapi-ui 1.6.12 -> 1.6.13 - update keycloak-admin-client 19.0.3 -> 20.0.2 - update com.google.protobuf 3.21.9 -> 3.21.11 - update openapi-generator-maven-plugin 6.2.0 -> 6.2.1 ### Added - introduce vavr.io library for neater code ### Changed - rename endpoint path to reflect API version (/api/22.04/selfdescription) - better error propagation from the Custodian to get more details on a error - update Spring Boot from 2.7.5 -> 2.7.6 - update springdoc-openapi-ui 1.6.12 -> 1.6.13 - update keycloak-admin-client 19.0.3 -> 20.0.2 - update com.google.protobuf 3.21.9 -> 3.21.11 - update openapi-generator-maven-plugin 6.2.0 -> 6.2.1
add support for all versions of Trust Framework in a single project
…ctory into all-versions
|
@carslen @Siegfriedk , can you please merge this PR? |
|
@dvasunin you are downgrading the helm chart version. Is that by misstake? Are you also aware that something like this might be broken as you should not reference github src like this? schema2210Url: https://github.com/catenax-ng/tx-sd-factory/raw/all-versions/src/main/resources/verifiablecredentials.jsonld/sd-document-v22.10.jsonld |
|
For Helm chart version I expect a comment from our devops, Aditya. For the JSON-LD vocabulary we need a media to refer to, e.g. the one you have mentioned. We need a publicly accessable space for these documents where they can be fetched from. As we have more than one repository, I decided to keep 'old' location, on further PR we can change it to TractusX location. If we do it from the beginning then the reference will be pointed to nowhere until merging. |
|
@dvasunin shouldn't that json-ld be part of some official deployment? Please revisit the architecture of this document and yes definitly move this to eclipse-tractusx if you really really really don't have any other way of exposing it |
|
The URLs of the semantic vocabularies shall be something stable, more stable than a deployment. And all deployments shall refer to the same vocabulary independently from environment. Technically we can have them deployment specific, but in my view it is not proper way: the service can go down, migrate, but the documents created with this vocabulary may stay. I do not see better place for them than GitHub itself as we need a 'stable' media. We can also have them deployed somewhere on official CatenaX page. But we do not have direct access to that page and the documents are updated sometimes. This is why we use GitHub as a media. We do not have any better option |
|
@dvasunin why would be a semantic vocabulary be more stable than a deployment? Or a release? Shouldn't it be enough to just release it with the version? IF this is more a spec, than you need to talk to @danielmiehle or someone else (architects etc.) on were/how to release a spec. |
|
We had this issue from the beginning, but nobody took it seriously and we kept vocabulary just 'somewhere' (initially as a Postman mock service, but it is even worse than github). I'll raise this quesion with our PO again. I belive the vocabularies shall be hosted on other places than service itself as the documents depending on them may outlive the service. These documents have link to the vocabulary which must be resolvable. Using github for this purpose is a kind of a hack, I agree. Let's put this PR on hold then until I clarify this with my PO @MehranRoshandel |
|
@dvasunin i'm fine with merging this PR after feedback regarding the helm chart, IF this topic continues to be driven. |
|
For helm chart version we have upgraded the version no. to 1.0.8 |
With this PR APIs for all supported versions of Trust Framework (TF) are made available under single service. Namely: