feat(2.1.1): add OCPI 2.1.1 support

[juherr]

Fix #183

Summary

• New independent module ocpi-toolkit-2.1.1 (BYOI — Bring Your Own Infrastructure philosophy)
• Full implementation of all 8 OCPI 2.1.1 modules: versions, credentials, locations, tokens, sessions, tariff, cdr, commands
• Dedicated Jackson and Kotlinx Serialization integrations (ocpi-toolkit-2.1.1-jackson, ocpi-toolkit-2.1.1-kotlinx-serialization)
• Parameterized HTTP tests (Jackson + Kotlinx) for each module — 0 failures

Key differences vs 2.2.1

• No chargingProfiles or hubclientinfo (not present in 2.1.1)
• Token: authId instead of contractId, no countryCode/partyId/energyContract
• Session / Cdr: inline identifiers, direct authId+authMethod, no cdrToken/cdrLocation
• Commands: synchronous response only (no async callback)
• Tariff: no type/minPrice/maxPrice
• Endpoint: identifier + url only — no role field (not part of 2.1.1 spec)
• VersionNumber: only knows V2_1_1; 2.2.1 adds V2_1_1 for version negotiation

Architecture

Each OCPI version is fully self-contained — no shared Gradle module between versions. The transport module remains pure infrastructure (HTTP abstractions only).

ocpi-toolkit (root)
├── annotation-processor/      # KSP processor (configurable via ocpiCommonPackage arg)
├── transport/                 # HTTP abstraction (infrastructure only)
├── ocpi-toolkit-2.2.1/        # OCPI 2.2.1 (self-contained)
├── ocpi-toolkit-2.1.1/        # NEW: OCPI 2.1.1 (self-contained)
└── integrations/
    ├── ocpi-toolkit-2.2.1-jackson/
    ├── ocpi-toolkit-2.2.1-kotlinx-serialization/
    ├── ocpi-toolkit-2.1.1-jackson/               # NEW
    └── ocpi-toolkit-2.1.1-kotlinx-serialization/ # NEW

CD pipeline

Release tags use a version suffix to publish independently:

• R-x.y.z-ocpi221 → publishes the 2.2.1 module pack to Maven Central
• R-x.y.z-ocpi211 → publishes the 2.1.1 module pack to Maven Central

Test plan

• ./gradlew :ocpi-toolkit-2.1.1:test — BUILD SUCCESSFUL
• ./gradlew :ocpi-toolkit-2.2.1:test — BUILD SUCCESSFUL (no regression)
• ./gradlew ktlintCheck — BUILD SUCCESSFUL

[juherr]

@lilgallon Here's an initial draft. Could you take a quick look and let me know if the overall direction aligns with your expectations?

[lilgallon]

The 2.1.1 code looks great overall, really good work on this, the implementation is clean and well-structured, thank you for your time working on that :)

A few points to address though:

1. No shared common module across versions (commit 74d56d3)

I'd rather avoid a shared Gradle common module for code shared between 2.1.1 and 2.2.1. Even if some code is common today, there's no guarantee it will remain so in 2.3.x and beyond. If the model evolves at some point, maintaining that shared code will quickly become painful.
This library implements a standard: once written, the code shouldn't change. Code deduplication only brings value when you anticipate future changes, which is not the case here. On top of that, introducing a common module would be a breaking change for existing users.
The Transport module is a good cautionary example: designed to be shared, it ended up embedding business logic (a role that doesn't exist in 2.1.1) that shouldn't have been there. It should have stayed purely infrastructure-oriented. This is why I prefer a module-per-OCPI-version approach. Now that 2.2.1 is stable, supporting a new version is just a matter of copying the code and making minor adjustments.

2. Separate CD pipelines per version

The ocpi-2-2-1 and ocpi-2-1-1 lifecycles differ, so the CD needs to be adjusted to build and publish only one module pack (= all the modules required for 2.2.1 or 2.1.1) at a time. This can be achieved by adding a suffix to the release tag (e.g. 1.0.0-ocpi221 / 1.0.0-ocpi211), which the CD pipeline can then parse to determine which "module pack" to publish to Maven Central.

3. Remove AI signatures from commits

While AI is a great tool for developing code against a well-defined spec, its use is currently limited at Izivia. Please remove any Claude-generated signatures from commit messages.

---

once again, thank you though :)

[sonarqubecloud]

Quality Gate passed

Issues
6 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
32.5% Duplication on New Code

See analysis details on SonarQube Cloud

[juherr]

@lilgallon Everything done