eclipse-tractusx / tractusx-edc

Tractus-X EDC (Eclipse Dataspace Connector)

Container images and deployments of the Eclipse Dataspace Components for the Tractus-X project.

Please also refer to:

• Our docs
• Our Releases
• Eclipse Dataspace Components
• Report Bug / Request Feature

About The Project

The project provides pre-built control- and data-plane docker images and helm charts of the Eclipse DataSpaceConnector Project.

Inventory

The eclipse data space connector is split up into Control-Plane and Data-Plane, whereas the Control-Plane functions as administration layer and has responsibility of resource management, contract negotiation and administer data transfer. The Data-Plane does the heavy lifting of transferring and receiving data streams.

Depending on your environment there are different derivatives of the control-plane prepared:

• edc-controlplane-postgresql-azure-vault with dependency onto
  • Azure Key Vault
  • PostgreSQL 8.2 or newer
• edc-controlplane-postgresql-hashicorp-vault with dependency onto
  • Hashicorp Vault
  • PostgreSQL 8.2 or newer

Derivatives of the Data-Plane can be found here

• edc-dataplane-azure-vault with dependency onto
  • Azure Key Vault
• edc-dataplane-hashicorp-vault with dependency onto
  • Hashicorp Vault

For testing/development purposes:

• edc-runtime-memory

Getting Started

Build

Build Tractus-X EDC together with its Container Images

./gradlew dockerize

License

Distributed under the Apache 2.0 License. See LICENSE for more information.

tractusx-edc's Issues

Refactor: remove lombok from `edc-extension::hashicorp-vault`

Remove lombok from the edc-extension::hashicorp-vault module

Subtask of #150

Helm Charts are still referring to product-edc container images

Describe the bug

The helm charts within this repository are still referring to the container images of the catena-x/product-edc github repository.

Expected behavior

After the first "real" release in this repository with published container images we should change this! (Or even right before it 😅)

Extend the tractusx-github.io "control Plane adpater" documentation

I want to get more information about the control plane adapter on tractusx-github.io

Within this PR a openAPI.yaml was generated. This should also be available in our kit documentation.

We also should be sure if the control plane adapter is documented in md. 

Tasks

• Adapt tractusx.github.io
• Generate mdx files out of openAPI file
• Link them
• Add documentation to tractusx.github.io (since we dont use submodules, this has to be done manual)

Charts testing

Helm supports testing out of the box for the Charts.
It would cool to introduce such testing in our CI pipeline.

We could probably use our Observability API for checking that the chart works as expected.

The docs for the Helm testing framework it's available here

Refactor: remove `transferprocess-sftp`

The transferprocess-sftp feature seems to be only used in tests at the moment. It should therefor be removed.

Is your feature request related to a problem? Please describe.
Lets keep the code base free of dead and unused code.

Describe the solution you'd like

• delete the transferprocess-sftp-* modules
• for the tests, write a small extensions that provides the same functionality in-memory and instrumentable for tests a DataSource, DataSink, etc.

Describe alternatives you've considered
maintaining these modules is not needed since it's only used in tests and no-one seems to be using them.

Additional context
.

veracode: High level vulnerabilities in transitive dependencies

Describe the bug

Veracode reported two vulnerabilities in transitive dependencies:

• json-smart-2.4.8.jar
• snakeyaml-1.33.jar

To Reproduce

check veracode report

Expected behavior

no high level vulnerabilities

Possible Implementation

force updated versions

Refactor: remove lombok from `edc-extension::data-control-plane-adapter`

Remove lombok from the edc-extension::data-control-plane-adapter module

Subtask of #150

Setup and implement publishing Maven artefacts to MavenCentral and OSSRH

WHAT

In order to have tractusx-edc consumable also on code-level we need to publish all artefacts to MavenCentral. In Eclipse projects that happens through an EF-managed Jenkins instance ("JIPP") that contains signing keys for MavenCentral.

WHY

MavenCentral requires all artefacts to be signed. That is done in Jenkins.

Implementation proposal

• remove the publishAllPublicationsToGithubPackagesRepository task
• GH Actions triggers Jenkins (through this action)
• on releases: the version parameter does not contain the -SNAPSHOT suffix, thus causing it to sync to MavenCentral
• use the credentials provided by this EF helpdesk ticket to sign the artefacts, and to publish to OSSRH/MavenCentral.
• No Jenkins instance is required, we can directly push to OSSRH!
• comment on this OSSRH issue once our first release is published successfully.

OPEN QUESTIONS

• what's our publishing schedule? Snapshots on every push to develop? Nightlies?
• do we already have a publishing environment set up?
• if not: who will open helpdesk issues with EF and OSSRH? -> done here
• should we host the declarative pipelines in a GitHub repo? (in EDC we do that)

[edit]: updated description based on not having to use Jenkins.

0.3.0 Charts to not reflect setting changes of the 0.3.0 image

Describe the bug

As it is now the charts to not reflect the changes from the migration guide.
https://github.com/catenax-ng/tx-tractusx-edc/blob/develop/docs/migration/Version_0.1.x_0.3.x.md

The affected charts are currently from the product-edc repository. But the idea would be to fix them here.

Affected charts:

catenax-ng-product-edc/edc-controlplane --version 0.3.0
catenax-ng-product-edc/edc-dataplane --version 0.3.0
catenax-ng-product-edc/tractusx-connector --version 0.3.0

Context Informations

• Used version: 0.3.0

_{Dominik Pinsel [email protected], Mercedes-Benz Tech Innovation GmbH, legal info/Impressum}

Switch over to using built-in repo secrets for publishing to GHCR.io

Currently the tractusx-edc repo is using a PAT to publish to GitHub Packages, which is not needed, as it can be done using built-in secrets.

Thus, all our workflows need to be updated to using this built-in secret.

Is your feature request related to a problem? Please describe.
.

Describe the solution you'd like
use the GITHUB_ACTOR and GITHUB_TOKEN secrets for publishing

Describe alternatives you've considered
re-creating a PAT, which is not necessary. Also, then forks would have to also create that PAT in case they want to publish to their own GHP.

Additional context
.

Bug: Docker images are not tagged with release version

Describe the bug

When creating a new release, for example 4.2.0, Docker images should be tagged with ...:4.2.0 (amongst others).
For some reason this does not happen.

To Reproduce

Create a new release version (DON'T DO THIS IN THE UPSTREAM!)

Expected behavior

the version tag is created

Screenshots/Error Messages

If applicable, add screenshots and/or error messages to help explain your problem.

Context Informations

first observed during the 0.3.3 release on April 19, 2023

Possible Implementation

My initial suspicion was, that either the docker/metadata-action does not pick up the newly created tag, or creating a tag does not trigger the build.yaml workflow.

On closer inspection, the reason turned out to be, that in order for workflows to be triggered from workflow runs, we apparently cannot use a GITHUB_TOKEN, but must use a PAT, according to the documentation. That means, that the workflow that creates the tag (i.e. publish_new_release.yaml) cannot run using a GITHUB_TOKEN, it must use a PAT, otherwise the other job, that publishes the image (build.yaml) won't execute. The solution could be as easy as to remove the permissions: block from the github-release job.

I tried it out by manually creating a Git tag, which did indeed trigger the workflow, and caused the correct Docker tag to be created.

Publish artefacts to well-known public locations

WHAT

To keep up the conventions of OSS projects we should publish our artefacts to publicly accessible and well-known locations, specifically:

• Docker Images -> hub.docker.com
• Maven Artefacts -> MavenCentral (and OSSRH Snapshots)
• Helm Charts -> ArtifactHub, and the TractusX Repo
• OpenAPI Specs -> SwaggerHub

WHY

OSS artefacts should be accessible to everyone without the need to authenticate or provide credentials.

FURTHER CONSIDERATIONS

For every artefact there are certain aspects to consider, for example Maven artefacts need to be published through an Eclipse Jenkins instance.
Docker images must come with a Notice, which must also be available on DockerHub, etc.

This issue serves as umbrella issue, to track several subtasks:

• #164
• #166
• Setup and implement publishing Helm Charts to ArtifactHub
• #295

Setup and implement publishing Docker images to DockerHub

Description

When publishing Docker images to GitHub packages in an Eclipse-managed Github repository, they are automatically set to private. This is an org-wide setting and cannot be changed.

Thus, we must publish our docker images to DockerHub.

Requirements

• image namespace and name must be defined as env variables
• we must use org-provided credentials to log into Dockerhub:

   - name: DockerHub login
        if: github.event_name != 'pull_request'
        uses: docker/login-action@v2
        with:
          username: ${{ secrets.DOCKER_HUB_USER }}
          password: ${{ secrets.DOCKER_HUB_TOKEN }}

• the README.md file must contain a Notice section, similar to the IRS example
• the description (by default: README.md) must get published to DockerHub as well using a GH Actions:

    - name: Update Docker Hub description
        if: github.event_name != 'pull_request'
        uses: peter-evans/dockerhub-description@v3
        with:
          username: ${{ secrets.DOCKER_HUB_USER }}
          password: ${{ secrets.DOCKER_HUB_TOKEN }}
          repository: ${{ env.IMAGE_NAMESPACE }}/${{ env.IMAGE_NAME }}

Implementation proposal

• leave publishing to GH Packages in for now, just to be safe
• Extract building and pushing docker images to a separate GH workflow publish-docker.yaml
• publish-docker.yaml runs only on pushes to develop and main and only if the Dockerhub credentials are present (prevents runs on forks)

GH Actions: replace all `set-output` with proper step outputs

WHAT

set-output is deprecated and using it will log a warning in GH Actions:

echo "::set-output name=commit::$(SOME_COMMAND)"

will result in a warning:

The set-output command is deprecated and will be disabled soon. Please upgrade to using Environment Files. For more information see: https://github.blog/changelog/2022-10-11-github-actions-deprecating-save-state-and-set-output-commands/

this needs to be done for all our workflows.

Create `tracusx-connector` chart

WHAT

Create the tractusx-connector chart including the following tasks:

• create the tractusx-runtime sub-chart
• create the tractusx-connector umbrella chart
• create chart tests
• add a matrix step in verify.yaml that executes the chart tests and some basic HTTP requests as outlined in the decision-record (#194)

Refactor Docker images

WHAT

The TractusX-EDC Docker images must be refactored to prepare for and reflect the planned changes to the Helm Charts

HOW

Excerpt rom the decision record:

The following changes need to be made to our Docker images:

• rename edc-controlplane-memory -> -edc-runtime-memory
• in edc-runtime-memory use FsVault instead of AzureVault
• edc-runtime-memory contains an embedded data plane
• rename edc-controlplane-postgresql -> edc-controlplane-postgresql-azure-vault
• delete edc-controlplane-memory-hashicorp-vault

thus effectively resulting in the following structure:

edc-controlplane
|-> edc-runtime-memory
|-> edc-controlplane-postgresql-hashicorp-vault
|-> edc-controlplane-postgresql-azure-vault

edc-dataplane
|-> edc-dataplane-hashicorp-vault
|-> edc-dataplane-azure-vaul

CI: run Trivy only when the `Build` job _actually_ ran

WHAT

We need to modify our trivy.yaml job to run only when the build.yaml workflow has actually ran. Currently, the Trivy job is executed as soon as the Build job has completed.

WHY

Trivy scans the docker images for vulnerabilities, and it uses the Git SHA as Docker tag. However, Docker images are not produced during pull requests or on forks, so the Trivy job cannot resolve the docker image, and thus will always fail.

IMPLEMENTATION PROPOSAL

1. Option 1: prevent Trivy runs on pull requests
   simply add if: ${{ github.event_name != 'pull_request' }} to the git-sha7 job. That will not prevent it from running in forks!

2. Option 2: use repository_dispatch and define a custom event
   Check here

3. Option 3: upload custom data using workflow_run
   Check the official documentation

Personally I think Option 3 is the most elegant one, because it will allow us to send a boolean flag (and potentially more data) as event payload, that indicates whether docker images were actually produced or not.

Ensure helm chart README.md's are in sync with the go-template

Is your feature request related to a problem? Please describe.
Currently if someone updates the go-template for our helm charts we don't have any automatism that performs the generation of the README.md files. This is therefore a manual step that could be forgotten or where typos can happen.

Describe the solution you'd like
Add a CI job that checks if both files are in sync with each other.

Describe alternatives you've considered
Automate the creation of the README.md files, but for that the question would be when do we want to do that 🤔 (see discussion in the linked PR below)

Additional context
Was discover in PR #261

Create `tractusx-connector-azure-vault` chart

WHAT

Create the tractusx-connector-azure-vault chart including the following tasks:

• create a copy of tractusx-connector
• update the Docker images
• replace the Hashicorp Vault config with the Azure KeyVault config
• create chart tests
• add a matrix step in verify.yaml that executes the chart tests and some basic HTTP requests as outlined in the decision-record (#194)

Log on Agreement Validation

WHAT

In the business partner validation we should ad a log entry (configurable) when evaluating the policy on ContractAgreement

If the ContractAgreement is present in the policy evaluation context we should log:

• business partner number
• contract id
• the result of the evaluation process

Object has already been returned to this pool or is invalid

Describe the bug

In edc-controlplane-postgresql an exception occurs during startup

Reported in Jira

To Reproduce

On startup from controlplane when you use the image edc-controlplane-postgresql

Screenshots/Error Messages

SEVERE 2023-04-05T08:06:08.375372 StateMachineManager [transfer-process] error caught
java.lang.IllegalStateException: Object has already been returned to this pool or is invalid
    at org.apache.commons.pool2.impl.BaseGenericObjectPool.markReturningState(BaseGenericObjectPool.java:1251)
    at org.apache.commons.pool2.impl.GenericObjectPool.returnObject(GenericObjectPool.java:1029)
    at org.eclipse.edc.sql.pool.commons.CommonsConnectionPool.returnConnection(CommonsConnectionPool.java:76)
    at org.eclipse.edc.sql.datasource.PooledDataSourceConnection.close(PooledDataSourceConnection.java:96)
    at org.eclipse.edc.connector.store.sql.transferprocess.store.SqlTransferProcessStore.lambda$nextForState$1(SqlTransferProcessStore.java:80)
    at org.eclipse.edc.transaction.spi.NoopTransactionContext.execute(NoopTransactionContext.java:34)
    at org.eclipse.edc.connector.store.sql.transferprocess.store.SqlTransferProcessStore.nextForState(SqlTransferProcessStore.java:69)
    at org.eclipse.edc.connector.transfer.process.TransferProcessManagerImpl.lambda$processTransfersInState$21(TransferProcessManagerImpl.java:591)
    at org.eclipse.edc.statemachine.StateProcessorImpl.process(StateProcessorImpl.java:46)
    at java.base/java.util.stream.ReferencePipeline$5$1.accept(Unknown Source)
    at java.base/java.util.ArrayList$ArrayListSpliterator.forEachRemaining(Unknown Source)
    at java.base/java.util.stream.AbstractPipeline.copyInto(Unknown Source)
    at java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(Unknown Source)
    at java.base/java.util.stream.ReduceOps$ReduceOp.evaluateSequential(Unknown Source)
    at java.base/java.util.stream.AbstractPipeline.evaluate(Unknown Source)
    at java.base/java.util.stream.LongPipeline.reduce(Unknown Source)
    at java.base/java.util.stream.LongPipeline.sum(Unknown Source)
    at org.eclipse.edc.statemachine.StateMachineManager.performLogic(StateMachineManager.java:118)
    at org.eclipse.edc.statemachine.StateMachineManager.lambda$loop$2(StateMachineManager.java:106)
    at io.micrometer.core.instrument.composite.CompositeTimer.record(CompositeTimer.java:79)
    at io.micrometer.core.instrument.Timer.lambda$wrap$0(Timer.java:160)
    at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
    at java.base/java.util.concurrent.FutureTask.run(Unknown Source)
    at java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(Unknown Source)
    at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
    at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
    at java.base/java.lang.Thread.run(Unknown Source)

Replace "maven" with "gradle" in the dependabot config

The dependabot config (.github/dependabot.yml) still has "maven" set as package ecosystem. that should be set to "gradle"

CI: extract the checkout and setup-java action into a re-usable action

WHAT

The checkout and setup-java actions should be extracted into a re-usable composite action.

In many workflow files we find multiple blocks of

      # Set-Up
      - name: Checkout
        uses: actions/[email protected]
      - name: Set up JDK 11
        uses: actions/[email protected]
        with:
          java-version: '17'
          distribution: 'temurin'
          cache: 'gradle'

which not only contains a small bug ("Set up JDK 11" instead of "17"), but it is also repetitive.

WHY

avoid duplication, create consistency, one place to maintain the code, e.g. for version upgrades

Refactor: remove lombok from `edc-extension::transferprocess-sftp-common`

Remove lombok from the edc-extension::transferprocess-sftp-common module

Subtask of #150

Cleanup obsolete branches

Currently, there are still two branches that are probably remnants of PRs that have already been merged:

• https://github.com/eclipse-tractusx/tractusx-edc/tree/chore/bump_chart_version which belongs to #97
• https://github.com/eclipse-tractusx/tractusx-edc/tree/chore/release_helm_chart_workflow which belongs to #96

@carslen, since you were the author of the two PRs, I took the liberty to assign this issue to you 😉

Consider all past releases in the CHANGELOG.md

Describe the bug

E.g. the Release 0.1.6 is missing in the CHANGELOG.md

Expected behavior

All release are listed in the CHANGELOG.md

Story: remove lombok

This issue tracks the progress of removing the lombok library from our codebase as per DR #143 .

This task will be divided in multiple subtasks for each module for keeping the PRs small and easy to review:

• edc-extension::data-control-plane-adapter
• edc-extension::data-encryption
• edc-extension::hashicorp-vault
• edc-extension::transferprocess-sftp-client
• edc-extension::transferprocess-sftp-common
• edc-extension::transferprocess-sftp-provisioner
• edc-tests

The last PR to be merged should remove also the dependency on lombok itself.

Subtasks

• #152
• #153
• #154
• #155
• #156
• #157
• #151

Refactor: remove lombok from `edc-extension::transferprocess-sftp-client`

Remove lombok from the edc-extension::transferprocess-sftp-client module

Subtask of #150

Ensure CHANGELOG.md will be updated in a proper way

Is your feature request related to a problem? Please describe.
At the moment the CHANGELOG.md is only been update from time to time and doesn't contain every PR we merged

Describe the solution you'd like
A process like in the upstream EDC repo: Let the changelog generated via the .github/release.yaml

Re-structure CI pipeline

Discussed in #227

^{Originally posted by paullatzelsperger April 17, 2023}

WHAT

This proposal is about re-structuring our CI pipelines as shown below to avoid spurious builds. Note that this merely deals with the test workflows (verify.yaml, deployment-test.yaml and business-tests.yaml) as well as the image- and package build (build.yaml).

We should restructure, such that every test stage triggers the subsequent one, and the last test stage triggers the build and publish.

In addition, during the release, we should only create the GH release once publishing to Docker, MavenCentral and Helm was successful.

WHY

CI workflows have a natural dependency onto one another, i.e. we should not publish Docker images or Maven packages unless all tests are green.

SOLUTION PROPOSAL

• rename build.yaml -> publish.yaml
• remove the build-extensions step, this is already covered by the unit-test job in verify.yaml
• allow the verify.yaml, deployment-test.yaml and business-tests.yaml flows to run in parallel.
• trigger the publish.yaml flow once all tests are green
• publish.yaml triggers trivy.yaml (same as now, no change)
• prevent publish.yaml from running on PRs and in forks (check via secrets presence)
• Make the github-release job dependent on [ 'maven-release','docker-release','helm-release']

FURTHER NOTES

• Waiting for multiple workflows is currently not supported, but a workaround could be to introduce an "all-in-one" workflow, that triggers the others within its jobs (which allows waiting).
• It should be noted that serializing/sequentializing workflows will result in overall longer CI runs. While this might be annoying, it is even more annoying to have "broken" Docker images or Maven packages.

Feature: enable unauthenticated access to Observability API

Currently, the ObservabilityAPI is put either under the "default" context, which causes the controller to log a warning, or under the management context, which requires authentication.
That is problematic if non-static authentication measures (OAuth2, OIDC,...) are used, where the auth-header changes over time.

Since the ObservabilityAPI is used for K8S health checks, the runtime log gets spammed with warnings.

Is your feature request related to a problem? Please describe.
Authenticated health endpoints may be problematic and cumbersome, and (effectively) periodic logs make the connector log hard to read.

Describe the solution you'd like
This is a two-staged solution:

• duplicate the ObservabilityAPI in tractusx-edc, and add a config flag to enable or disable auth
• eventually upstream this flag to EDC, and remove the tractusx-edc duplicate again

Describe alternatives you've considered

• instead of duplicating, we could just re-register the controllers, but we'd end up with two controllers, giving uns effectively the same result. And a separate extension would be needed anyway.

Additional context
Changes to the helm chart, the changelog, readme and migration guide will be necessary

Create `tractusx-connector-memory` chart

WHAT

Create the tractusx-connector-memory chart including the following tasks:

• refactor Docker images as per decision record
• update the runtime to use FsVault instead of Azure KeyVault
• remove opentelemetry agent
• create chart
• create chart tests
• add a matrix step in verify.yaml that executes the chart tests and some basic HTTP requests as outlined in the decision-record (#194)

Refactor Helm charts

WHAT

The TractusX-EDC Helm charts need to be refactored such that the currently "dynamically composed" chart is replaced by several focused an clearly delineated charts, while still preserving a measure of extensibility and flexibility.

WHY

We do this to combat several issues we've encountered in the past, such as difficulties isolating supposed bugs and configuration errors, as well as to sharpen the focus on what is actually provided by TractusX-EDC.

HOW

The rationale and approach are outlined in a decision record (PR #194).

SUBTASKS

• #194
• #198 (should be done first)
• #195
• #196
• #197 #279

Refactor: remove lombok from `edc-extension::transferprocess-sftp-provisioner`

Remove lombok from the edc-extension::transferprocess-sftp-provisioner module

Subtask of #150

Replace the backend service from the business tests

The "backend service" currently used by the supporting-infrastructure tests is hosted in a non-eclipse repository, supposedly written in javascript.

We need to get rid of this and replace it with a small mock in our tests.

Is your feature request related to a problem? Please describe.
We cannot have private resources in our code base, that are obscure and over which we have no control.

Describe the solution you'd like
remove - replace with a mock/stub

Describe alternatives you've considered
none

Additional context
.

Refactor: remove lombok from `edc-extension::data-encryption`

Remove lombok from the edc-extension::data-encryption module

Subtask of #150

Adapt documentation – Add link to product installation manual in root readme.md

The installation manual for the tractusx-edc is not easy to find. For new user, it should be mentioned and also linked in the README.md (root)

It is also a requirement for the FOSS QGate.

Re-structure CI pipeline

WHAT

This proposal is about re-structuring our CI pipelines as shown below to avoid spurious builds. Note that this merely deals with the test workflows (verify.yaml, deployment-test.yaml and business-tests.yaml) as well as the image- and package build (build.yaml).

We should restructure, such that every test stage triggers the subsequent one, and the last test stage triggers the build and publish.

WHY

CI workflows have a natural dependency onto one another, i.e. we should not publish Docker images or Maven packages unless all tests are green.

SOLUTION PROPOSAL

• rename build.yaml -> publish.yaml
• remove the build-extensions step, this is already covered by the unit-test job in verify.yaml
• allow the verify.yaml, deployment-test.yaml and business-tests.yaml flows to run in parallel.
• trigger the publish.yaml flow once all tests are green
• publish.yaml triggers trivy.yalm (same as now, no change)
• prevent publish.yaml from running on PRs and in forks (check via secrets presence)

FURTHER NOTES

Waiting for multiple workflows is currently not supported, but a workaround could be to introduce an "all-in-one" workflow, that triggers the others within its jobs (which allows waiting).

Rename Git branches

WHAT

We require the following renaming of Git branches:

• main -> releases (will track all the releases)
• develop -> main (will be our default branch)
• delete develop

WHY

The renaming is necessary to comply with TractusX Release Guidelines, but also being able to leverage the benefits of GitFlow, as well as convenience features of GitHub itself (e.g. automatic PR->issue linking, default branch checkouts, etc.).

The decision is outlined in this decision record.

IMPORTANT

• All open PRs may need to be manually re-targeted before develop is deleted!
• Do this at a time where little disruption is expected, e.g. during night time or a weekend.

Get rid of deprecated charts

Currently we have "deprecated" charts that aren't providing value and they are a pain to maintain.

Is your feature request related to a problem? Please describe.
Maintenance of dead code

Describe the solution you'd like
Delete the edc-controlplane and edc-dataplane charts, as they have been replaced by the tractus-connector one

Describe alternatives you've considered
.

Additional context
.

Add ci job for markdown linting

Is your feature request related to a problem? Please describe.
Yes, we need to provide some documentation for the repo (https://github.com/eclipse-tractusx/eclipse-tractusx.github.io). In this repo they are already using a CI job which lints all their markdown files and it was a huge task to fix all our markdown files manually.

Describe the solution you'd like
To always have proper formatted markdown files, it would be great to have a CI job which checks all added or modified markdown files of a PR.

Additional context
The repo https://github.com/eclipse-tractusx/eclipse-tractusx.github.io uses at the moment the npm package markdownlint-cli2 for linting the markdown files. The author of the npm package provides also a GitHub Action which could be used: https://github.com/marketplace/actions/markdownlint-cli2-action

Fix license header to match Eclipse recommendations

Please fix license header in src code files to match Eclipse recommendations.

Refactor: remove private backendservice from helmcharts

Right now there is a private backend service used (from a private repository) within our helmchart

The service is used in the supporting infrastructure helm chart

Private service/repository here

Within this ticket, it should be analyzed if we really need this service. If we require it we should think about how to redevelop it and also store it in our repository or under a separate repository under tractusx.

Tasks

• Analyze the service
• extract the service
• store it in a new repository
• link the new service in the helm chart

Create basic rules and guidelines

Is your feature request related to a problem? Please describe.
This issue deals with creating OSS ground rules that all committers and contributors must adhere to. It does not involve any code, but it will provide guidelines for how code is contributed.

Describe the solution you'd like
A couple of files, initially:

• CONTRIBUTING.md: will establish general contribution guide lines, e.g. opening discussions first
• PR_ETIQUETTE.md: will establish rules specifically about pull requests, both for authors and reviewers
• code_style.md: defines how code will look like. this will be encorced using checkstyle, but initially all checkstyle errors will be treated as warnings.

Describe alternatives you've considered
none. this is the bare minimum for OSS.

Additional context
We should strive to adopt as many of EDC's rules and guides, with small adaptations, because that will ensure a high degree of compatibility when upstreaming features, and it will leverage an already battle-proven system.

Refactor: remove lombok from `edc-tests`

Remove lombok from the edc-tests module

Subtask of #150

Repo doesn't follow git-flow workflow

Describe the bug

In this repository the default branch is configured to be the main branch and currently all PRs are merged against it and also some commits were pushed directly on main. If I'm correct, the Catena-X Product-EDC repository uses the git-flow, which means that only the releases were merged to the main branch and the development happened on the develop branch. That means also, that the develop branch contains features and commits which weren't merged to main until now (e.g. on the develop branch all the maven group id's were already change regarding the migration from Catena-X Product-EDC to tractusx-edc).

As there are now already additional commits on the main branch which are not on the develop, the two branches are drifted away from each other, which makes it difficult to continue the migration from Catena-X Product-EDC to tractusx-edc.

Expected behavior/Possible solution

For an easier migration I would expect that the same git workflow would been used from the beginning of the migration until the end of the migration. But as it isn't the case, we need to align how we want to continue and how to clean up the repository again and if we still want to go with the git flow or not.

If we want to go with the git flow, I would recommend to do the following to clean up the repository again:

• Merge main into develop and fix all the merge conflics
• Make develop the default branch

If we don't want to go with the git flow:

• Merge develop into main and fix all the merge conflics
• Use main as the starting point for what ever git workflow we want to follow

Use Eclipse Temurin as Docker base image

All docker images that run java code should use the Eclipse Temurin base image instead of Alpine + OpenJDK.

Is your feature request related to a problem? Please describe.
Eclipse Temurin is the recommended one, and it is also an Eclipse project.

Describe the solution you'd like

• swap out all base images, remove the apk upgrade lines
• replace the base distribution in the test pipeline:
  distribution: 'adopt' --> distribution: 'temurin'

Describe alternatives you've considered
.

Additional context
should be done after #125 is merged, because that PR will modify Dockerfiles as well.

Adapt Postman collection for v0.3.x

WHAT
The current Postman collection URL are pointing to /data/ and should be use /management/ as it is the default setup.
To make it more flexibel the URL prefix like /management/ should be added to variable definition.

Example variable definition:
{{PROVIDER_DATAMGMT_URL}}/data/assets -> {{PROVIDER_DATAMGMT_URL}}/assets where {{PROVIDER_DATAMGMT_URL}} would look like <host>:<port>/management

Add Control Plane Adapter calls to the collection

TractusX Helm Chart: setting either the `vault.azure.clientsecret` _or_ `vault.azure.certificate` does not work

Describe the bug

Setting the vault.azure.clientsecret value to authenticate against an Azure KevVault does not work, because it always gets overwritten by vault.azure.certificate.

The reason is that the respective environment variables (EDC_VAULT_CERTIFICATE and EDC_VAULT_CLIENTSECRET) are always set, even when vault.azure.certificate is not configured, and they have a default value of "" (empty string).

Then, the AzureVaultExtension checks if the certificate path is null, which it isn't (because it's ""), and tries to interpret the empty string as certificate path, which obviously fails.

Possible Implementation

setting the environment variables only if the respective Values exist:

# only set the env var if config value not null
{{- if .Values.vault.azure.secret }}
- name: "EDC_VAULT_CLIENTSECRET"
  value: {{ .Values.vault.azure.secret | quote }}
{{- end }}

Control Plane Adapter callback integration

What

In EDC upstream there has been some work for supporting callbacks in the state machines, in particular in the Contract Negotiation process and in the Transfer process.
We should integrate in the callback system and provide a simplified API for "opening" a Transfer with only one request.

The output of the "opening" a transfer will be an EDR store in the CPA which will come in future PR. For now it will just
fire a transfer request of type HttpProxy and if an EDR receiver is configured it will be called.

Why

Simplification of the Control plane adapter without breaking the semantics of EDC.