Restore OCPI 2.1.1

[juherr]

As this project aims to be the reference Kotlin library for implementing the OCPI (Open Charge Point Interface) protocol,

it would be valuable to support OCPI 2.1.1 as well.

This version is still actively used in production by several actors, and supporting it would also allow the toolkit to serve as a solid foundation for implementing version conversion or backward-compatibility layers (e.g. 2.1.1 ↔ 2.2.x).

A related implementation already existed in the past and could potentially be reused or adapted: 83c1f11

[lilgallon]

Now that version 2.2.1 has been fully implemented and is being used by several parties in production, adding support for version 2.1.1 to the library is now feasible. Our current implementation has reached a stable state that meets our needs, which wasn't the case when we initially removed 2.1.1 support to avoid the overhead of backporting each 2.2.1 design change to 2.1.1.

We're open to accepting a PR that reintroduces 2.1.1 support. Personally, I do not have enough time to work on it for now

[juherr]

Great! I should have some availability starting next year and will take a look at the effort required to migrate my existing 2.1.1 implementation into this project, rather than reimplementing 2.2.1 from scratch on my own.

[juherr]

@lilgallon Currently, the ocpi-toolkit-2.2.1 module uses a generic package name for its model classes. If we introduce an ocpi-toolkit-2.1.1 module, reusing the same package structure would inevitably lead to naming conflicts between the two versions.

It might be worth considering a strategy similar to the one used in the ocpp-toolkit, where versioned packages help keep concerns clearly separated while remaining manageable.

What approach would you recommend for handling package naming across different OCPI versions in a way that avoids conflicts and keeps the API consistent and maintainable?

[lilgallon]

Indeed, I think using com.izivia.ocpi.toolkit.v211 instead of com.izivia.ocpi.toolkit would be a great approach, as it aligns nicely with the artifact name ocpi-toolkit-2-1-1.

I would prefer not to update the packages of the existing 2.2.1 version to avoid introducing breaking changes, at least for now. We could consider updating it in the future when another breaking change is expected anyway (we should create a github issue for that)

Also, I think the versioning should be independent so that a change in ocpi-2-1-1 doesn't necessarily require a new version for the ocpi-2-2-1 artifact. I can handle this once the 2.1.1 module is bootstrapped. The same applies to the transport artifact (which should already be the case, actually).

I'm open to feedback if you have another approach to propose :)