Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

link from the plugin docu to architecture docu #612

Merged
merged 3 commits into from
Jan 9, 2024
Merged
Changes from 2 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
8 changes: 4 additions & 4 deletions java/plugins.md
Original file line number Diff line number Diff line change
Expand Up @@ -33,17 +33,17 @@ When building CAP Java plugin modules, you need to keep in mind that the generat
Of course, it's up to your project / plugin how you call the corresponding Maven GroupId and Java packages. To avoid confusion and also to make responsibilities clear `com.sap.cds` for GroupId and Java package names are reserved for components maintained by the CAP Java team and must not be used for external plugins. This rule also includes substructures to `com.sap.cds` like `com.sap.cds.foo.plugin`.


## Sharing Reusable CDS Models via Maven Artifacts
## Share CDS Models via Maven Artifacts

Before the CAP Java 2.2 release CDS definitions had to be shared as node.js modules, also for Java projects.

Starting with the 2.2 release CDS models, CSV import data and i18n files can now be shared through Maven dependencies in addition to npm packages. This means you can now provide CDS models, CSV files, i18n files, and Java code (for example, event handlers) in a single Maven dependency.

### Create the Reuse Model in a New Maven Artifact
### Create the CDS Model in a New Maven Artifact

Simply create a plain Maven Java project and place your CDS models in the `main/resources/cds` folder of the reuse package under a unique module directory (for example, leveraging group ID and artifact ID): `src/main/resources/cds/com.sap.capire/bookshop/`. With `com.sap.capire` being the group ID and `bookshop` being the artifact ID.

### Reference the Reuse Model in an Existing CAP Java Project
### Reference the New CDS Model in an Existing CAP Java Project

Projects wanting to import the content simply add a Maven dependency to the reuse package to their _srv/pom.xml_ in the `<dependencies>` section.

Expand Down Expand Up @@ -190,7 +190,7 @@ A complete end-to-end example for reusable event handlers can be found in this [

## Custom Protocol Adapters {#protocol-adapter}

In CAP Java, the protocol adapter is the mechanism to implement inbound communication (another service or the UI) to the CAP service in development. The task of a protocol adapter is to translate any incoming requests of a defined protocol to CQL statements that then can be executed on locally defined CDS services. CAP Java comes with 3 protocol adapters (OData V2 and V4, and HCQL) but can be extended with custom implementations. In this section, you have a deeper look on how such a protocol adapter can be built and registered with the CAP Java runtime.
In CAP, the protocol adapter is the mechanism to implement inbound communication (from another service or the UI) to the CAP service in development. You can read more about protocol adapters in our [architecture documentation](java/architecture#protocol-adapters).

Usually, a protocol adapter comes in 2 parts:

Expand Down