feat: clearinghouse integration (#2)

* feat: init clearinghouse extension

Co-authored-by: omar <omar.silva@sovity.de>

Author: tmberthold

CHANGELOG.md

@@ -7,8 +7,10 @@ All notable changes to this project will be documented in this file.
 - Add additional meta information to resource payload when publishing to broker
 - Add connector description to broker message
 - Add time-interval and participant based policies
+- Add ClearingHouse Extension
 
 ### Changed
+- Modified module structure to have only one Boker and one ClearingHouse Extension
 - Bump junit-jupiter-api from 5.8.1 to 5.9.2
 - Bump junit-jupiter-engine from 5.8.1 to 5.9.2
 - Bump com.github.johnrengelman.shadow from 7.0.0 to 7.1.2

CODE_OF_CONDUCT.md

@@ -0,0 +1,70 @@
+# Code of Conduct
+## Our Pledge
+
+In the interest of fostering an open and welcoming environment, we as
+contributors and maintainers pledge to making participation in our project and
+our community a harassment-free experience for everyone, regardless of age, body
+size, disability, ethnicity, gender identity and expression, level of experience,
+nationality, personal appearance, race, religion, or sexual identity and
+orientation.
+
+## Our Standards
+
+Examples of behavior that contributes to creating a positive environment
+include:
+
+* Using welcoming and inclusive language
+* Being respectful of differing viewpoints and experiences
+* Gracefully accepting constructive criticism
+* Focusing on what is best for the community
+* Showing empathy towards other community members
+
+Examples of unacceptable behavior by participants include:
+
+* The use of sexualized language or imagery and unwelcome sexual attention or
+  advances
+* Trolling, insulting/derogatory comments, and personal or political attacks
+* Public or private harassment
+* Publishing others' private information, such as a physical or electronic
+  address, without explicit permission
+* Other conduct which could reasonably be considered inappropriate in a
+  professional setting
+
+## Our Responsibilities
+
+Project maintainers are responsible for clarifying the standards of acceptable
+behavior and are expected to take appropriate and fair corrective action in
+response to any instances of unacceptable behavior.
+
+Project maintainers have the right and responsibility to remove, edit, or
+reject comments, commits, code, wiki edits, issues, and other contributions
+that are not aligned to this Code of Conduct, or to ban temporarily or
+permanently any contributor for other behaviors that they deem inappropriate,
+threatening, offensive, or harmful.
+
+## Scope
+
+This Code of Conduct applies both within project spaces and in public spaces
+when an individual is representing the project or its community. Examples of
+representing a project or community include using an official project e-mail
+address, posting via an official social media account, or acting as an appointed
+representative at an online or offline event. Representation of a project may be
+further defined and clarified by project maintainers.
+
+## Enforcement
+
+Instances of abusive, harassing, or otherwise unacceptable behavior may be
+reported by contacting the project team. All
+complaints will be reviewed and investigated and will result in a response that
+is deemed necessary and appropriate to the circumstances. The project team is
+obligated to maintain confidentiality with regard to the reporter of an incident.
+Further details of specific enforcement policies may be posted separately.
+
+Project maintainers who do not follow or enforce the Code of Conduct in good
+faith may face temporary or permanent repercussions as determined by other
+members of the project's leadership.
+
+## Attribution
+
+This Code of Conduct is adapted from the [Contributor Covenant](http://contributor-covenant.org),
+version 1.4, available at http://contributor-covenant.org/version/1/4.

CONTRIBUTING.md

@@ -0,0 +1,162 @@
+# Contributing to the Project
+
+Thank you for your interest in contributing to this project
+
+## Table of Contents
+
+* [Code Of Conduct](#code-of-conduct)
+* [How to Contribute](#how-to-contribute)
+    * [Discuss](#discuss)
+    * [Create an Issue](#create-an-issue)
+    * [Submit a Pull Request](#submit-a-pull-request)
+    * [Report on Flaky Tests](#report-on-flaky-tests)
+* [Etiquette for pull requests](#etiquette-for-pull-requests)
+* [Contact Us](#contact-us)
+
+## Code Of Conduct
+
+See the [Code Of Conduct](CODE_OF_CONDUCT.md).
+
+## How to Contribute
+
+### Discuss
+
+If you want to share an idea to further enhance the project or discuss potential use cases, please feel free to create a
+discussion at the `GitHub Discussions page`]
+If you feel there is a bug or an issue, contribute to the discussions in `existing issues`
+otherwise [create a new issue](#create-an-issue).
+
+### Create an Issue
+
+If you have identified a bug or want to formulate a working item that you want to concentrate on, feel free to create a
+new issue at our project's corresponding `GitHub Issues page`. Before doing so, please consider searching for
+potentially suitable `existing issues`.
+
+We also
+use [GitHub's default label set](https://docs.github.com/en/issues/using-labels-and-milestones-to-track-work/managing-labels)
+extended by custom ones to classify issues and improve findability.
+
+If an issue appears to cover changes that will have a (huge) impact on the code base and needs to
+first be discussed, or if you just have a question regarding the usage of the software, please
+create a `discussion` before raising an issue.
+
+Please note that if an issue covers a topic or the response to a question that may be interesting
+for other developers or contributors, or for further discussions, it should be converted to a
+discussion and not be closed.
+
+### Adhere to Coding Style Guide
+
+We aim for a coherent and consistent code base, thus the coding style detailed in the [styleguide](STYLEGUIDE.md) should
+be followed.
+
+### Submit a Pull Request
+
+We would appreciate if your pull request applies to the following points:
+
+* Conform to following [Etiquette for pull requests](#etiquette-for-pull-requests):
+
+* Make sure to adjust copyright headers appropriately.
+
+* The git commit messages should comply to the following format:
+    ```
+    <prefix>(<scope>): <description>
+    ```
+
+  Use the [imperative mood](https://github.com/git/git/blob/master/Documentation/SubmittingPatches)
+  as in "Fix bug" or "Add feature" rather than "Fixed bug" or "Added feature" and
+  [mention the GitHub issue](https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue)
+  e.g. `chore(transfer process): improve logging`.
+
+* Add meaningful tests to verify your submission acts as expected.
+
+* Where code is not self-explanatory, add documentation providing extra clarification.
+
+* PR descriptions should use the current [PR template](.github/PULL_REQUEST_TEMPLATE.md)
+
+* Submit a draft pull request at early-stage and add people previously working on the same code as
+  reviewer. Make sure automatic checks pass before marking it as "ready for review":
+
+    * _Continuous Integration_ performing various test conventions.
+
+### Report on Flaky Tests
+
+If you discover a randomly failing ("flaky") test, please take the time to check whether an issue for that already
+exists and if not, create an issue yourself, providing meaningful description and a link to the failing run. Please also
+label it with `Bug` and `github`. Then assign it to whoever was the original author of the relevant piece of code or
+whoever worked on it last. If assigning the issue is not possible due to missing rights, please just comment and
+@mention the author/last editor.
+
+Please do not just restart the run, as this would overwrite the results. If you need to, a better way of doing this is
+to push an empty commit. This will trigger another run.
+
+```bash
+git commit --allow-empty -m "trigger CI" && git push
+```
+
+If an issue labeled with `Bug` and `github` is assigned to you, please prioritize addressing this issue as other
+people will be affected.
+We are taking the quality of our code very serious and reporting on flaky tests is an important step toward improvement
+in that area.
+
+## Etiquette for pull requests
+
+### As an author
+
+Submitting pull requests should be done while adhering to a couple of simple rules.
+
+- Familiarize yourself with [coding style](STYLEGUIDE.md), architectural patterns and other contribution guidelines.
+- No surprise PRs please. Before you submit a PR, open a discussion or an issue outlining your planned work and give
+  people time to comment. It may even be advisable to contact committers using the `@mention` feature. Unsolicited PRs
+  may get ignored or rejected.
+- Create focused PRs: your work should be focused on one particular feature or bug. Do not create broad-scoped PRs that
+  solve multiple issues as reviewers may reject those PR bombs outright.
+- Provide a clear description and motivation in the PR description in GitHub. This makes the reviewer's life much
+  easier. It is also helpful to outline the broad changes that were made, e.g. "Changes the schema of XYZ-Entity:
+  the `age` field changed from `long` to `String`".
+- If you introduce new 3rd party dependencies, be sure to note them in the PR description and explain why they are
+  necessary.
+- Stick to the established code style, please refer to the [styleguide document](STYLEGUIDE.md).
+- All tests should be green, especially when your PR is in `"Ready for review"`
+- Mark PRs as `"Ready for review"` only when you're prepared to defend your work. By that time you have completed your
+  work and shouldn't need to push any more commits other than to incorporate review comments.
+- Merge conflicts should be resolved by squashing all commits on the PR branch, rebasing onto `main` and
+  force-pushing. Do this when your PR is ready to review.
+- If you require a reviewer's input while it's still in draft, please contact the designated reviewer using
+  the `@mention` feature and let them know what you'd like them to look at.
+- Re-request reviews after all remarks have been adopted. This helps reviewers track their work in GitHub.
+- If you disagree with a committer's remarks, feel free to object and argue, but if no agreement is reached, you'll have
+  to either accept the decision or withdraw your PR.
+- Be civil and objective. No foul language, insulting or otherwise abusive language will be tolerated.
+- The PR titles must follow [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/).
+    - The title must follow the format as `<type>(<optional scope>): <description>`.
+      `build`, `chore`, `ci`, `docs`, `feat`, `fix`, `perf`, `refactor`, `revert`, `style`, `test` are allowed for
+      the `<type>`.
+    - The length must be kept under 80 characters.
+
+### As a reviewer
+
+- Have a look at [Pull Request Review Pyramide](https://www.morling.dev/blog/the-code-review-pyramid/)
+- Please complete reviews within two business days or delegate to another committer, removing yourself as a reviewer.
+- If you have been requested as reviewer, but cannot do the review for any reason (time, lack of knowledge in particular
+  area, etc.) please comment that in the PR and remove yourself as a reviewer, suggesting a stand-in.
+- Don't be overly pedantic.
+- Don't argue basic principles (code style, architectural decisions, etc.)
+- Use the `suggestion` feature of GitHub for small/simple changes.
+- The following could serve you as a review checklist:
+    - no unnecessary dependencies in `build.gradle.kts`
+    - sensible unit tests, prefer unit tests over integration tests wherever possible (test runtime). Also check the
+      usage of test tags.
+    - code style
+    - simplicity and "uncluttered-ness" of the code
+    - overall focus of the PR
+- Don't just wave through any PR. Please take the time to look at them carefully.
+- Be civil and objective. No foul language, insulting or otherwise abusive language will be tolerated. The goal is to
+  _encourage_ contributions.
+
+## Contact Us
+
+If you have questions or suggestions, do not hesitate to contact the project developers via https://github.com/sovity.
+
+## Attribution
+
+This file is adapted from the [eclipse-edc](https://github.com/eclipse-dataspaceconnector/DataSpaceConnector) project.

README.md

@@ -1,7 +1,12 @@
-# EDC-Connector Broker Extension
-To get started, a sample docker-compose file is located in the resources/docs folder.
+# EDC-Connector Extensions
+
+## About The Project
+In this repo are different extensions of the EDC-Connector, among others a Broker-Extension to communicate with an IDS-Broker as well as a ClearingHouse-Extension to communicate with an IDS-ClearingHouse.
+
+## Getting Started
+
+To get started and run the extensions with an EDC, a sample docker-compose file is located in the resources/docs folder.
 
-## Run extension with EDC
 ### Configuration
 #### Basic Configuration
 - `EDC_IDS_TITLE`: _Title of the Connector_
@@ -15,6 +20,7 @@ To get started, a sample docker-compose file is located in the resources/docs fo
 #### MDS Environment Configuration
 The dev environment is set by default.
 - `EDC_BROKER_BASE_URL:` https://broker.dev.mobility-dataspace.eu
+- `EDC_CLEARINGHOUSE_LOG_URL`: https://clearing.dev.mobility-dataspace.eu/messages/log
 - `EDC_OAUTH_CLIENT_ID:` _To be able to start an EDC-Connector with the broker-extensions, the `SKI` and `AKI` of the connector certificate must be entered as `client-ID` in the docker-compose and the .jks must be placed under the path specified in the docker-compose (in the example in the folder `resources/vault/edc/`, see `EDC_KEYSTORE` setting)._
 - `EDC_OAUTH_TOKEN_URL:` https://daps.dev.mobility-dataspace.eu/token
 - `EDC_OAUTH_PROVIDER_JWKS_URL:` https://daps.dev.mobility-dataspace.eu/jwks.json
@@ -75,3 +81,6 @@ Copy the SKI:AKI combination and use it to start the EDC (optionally also save i
 
 ## License
 This project is licensed under the Apache License 2.0 - see [here](LICENSE) for details.
+
+## Contact
+Sovity GmbH Support - support@sovity.de 

SECURITY.md

@@ -0,0 +1,32 @@
+## Security
+
+sovity GmbH takes the security of its software products and services seriously, which includes all source code repositories managed through our GitHub organization: [sovity](https://github.com/sovity).
+
+If you believe you have found a security vulnerability in any of sovity's owned repositories, please report it to us as described below.
+
+## Reporting Security Issues
+
+**Please do not report security vulnerabilities through public GitHub issues.**
+
+Instead, please report them via mail: [security@sovity.de](mailto:security@sovity.de)
+
+You should receive a response within 24 hours. If for some reason you do not, please follow up via email to ensure we received your original message.
+
+Please include the requested information listed below (as much as you can provide) to help us better understand the nature and scope of the possible issue:
+
+* Type of issue (e.g. buffer overflow, SQL injection, cross-site scripting, etc.)
+* Full paths of source file(s) related to the manifestation of the issue
+* The location of the affected source code (tag/branch/commit or direct URL)
+* Any special configuration required to reproduce the issue
+* Step-by-step instructions to reproduce the issue
+* Proof-of-concept or exploit code (if possible)
+* Impact of the issue, including how an attacker might exploit the issue
+
+This information will help us triage your report more quickly.
+
+## Preferred Languages
+
+We prefer all communications to be in English.
+
+## Attribution
+This file is adapted from [eclipse-edc](https://github.com/eclipse-edc/DataDashboard) project.

build.gradle.kts

@@ -80,4 +80,4 @@ subprojects {
             }
         }
     }
-}
+}

connector/build.gradle.kts

@@ -8,10 +8,11 @@ val edcVersion: String by project
 val edcGroup: String by project
 
 dependencies {
-    implementation(project(":extensions:catalog-transfer-extension"))
-    implementation(project(":extensions:event-asset-provider"))
+    implementation(project(":extensions:broker"))
+    implementation(project(":extensions:clearinghouse"))
     implementation(project(":extensions:policy-referringConnector"))
     implementation(project(":extensions:policy-timeinterval"))
+
     implementation("${edcGroup}:control-plane-core:${edcVersion}")
     implementation("${edcGroup}:api-observability:${edcVersion}")
     implementation("${edcGroup}:data-management-api:${edcVersion}")

extensions/broker/README.md

@@ -0,0 +1,16 @@
+# EDC-Connector Broker Extensions
+To get started, a sample docker-compose file is located in the /resources/docs folder.
+
+## Configuration
+Settings required for this extension:
+
+- `EDC_BROKER_BASE_URL:` https://broker.dev.mobility-dataspace.eu
+- `EDC_CONNECTOR_NAME:` _The name of the connector_ 
+- `EDC_IDS_DESCRIPTION`: _Description of the Connector_
+- `EDC_IDS_CURATOR:` _URL of the curator, i.e. the company, which configures data offerings etc._
+
+## License
+This project is licensed under the Apache License 2.0.
+
+## Contact
+sovity GmbH support - support@sovity.de

extensions/broker/build.gradle.kts

@@ -0,0 +1,33 @@
+plugins {
+    `java-library`
+}
+
+val edcVersion: String by project
+val edcGroup: String by project
+val jupiterVersion: String by project
+val mockitoVersion: String by project
+val assertj: String by project
+val okHttpVersion: String by project
+
+dependencies {
+    implementation("${edcGroup}:control-plane-core:${edcVersion}")
+    implementation("${edcGroup}:ids-spi:${edcVersion}")
+    implementation("${edcGroup}:ids-api-multipart-dispatcher-v1:${edcVersion}")
+    implementation("${edcGroup}:ids-api-configuration:${edcVersion}")
+    implementation("${edcGroup}:ids-jsonld-serdes:${edcVersion}")
+
+    implementation("com.squareup.okhttp3:okhttp:${okHttpVersion}")
+
+    testImplementation("org.assertj:assertj-core:${assertj}")
+    testImplementation("org.junit.jupiter:junit-jupiter-api:${jupiterVersion}")
+    testImplementation("org.mockito:mockito-core:${mockitoVersion}")
+    testImplementation("org.mockito:mockito-core:${mockitoVersion}")
+    testImplementation("org.junit.jupiter:junit-jupiter-params:${jupiterVersion}")
+    testRuntimeOnly("org.junit.jupiter:junit-jupiter-engine:${jupiterVersion}")
+}
+
+tasks.getByName<Test>("test") {
+    useJUnitPlatform()
+}
+
+tasks.register("prepareKotlinBuildScriptModel"){}