Which OCPI project to use as a foundation?

[goekay]

Hey there, I am the maintainer of https://github.com/steve-community/steve

I am beginning to think and plan the first steps regarding an OCPI extension for steve. In that regard, I am trying to find an existing unopinionated library that includes all relevant data models + HTTP interfaces.

• OCPI 2.2.1 d2 + Direct Payments Module
• OCPI 2.3 (nice to have)

If complete and correct OpenAPI spec exists, I would gladly take that. Otherwise, I am looking for Java.

Having gone through the list, I find something missing/negative with almost each project that is relevant to me. Most are old and inactive. And hence, my question.

Thanks in advance!

[juherr]

Hello Sevket,

I'll try to stay cautious regarding version coverage. From an architectural point of view, I would suggest starting with support for a single OCPI version rather than aiming for native multi-version support right away.
Supporting multiple OCPI versions usually adds a lot of complexity. In many ecosystems, this is handled by dedicated interoperability or translation layers (for example, ENAPI or similar services). Keeping SteVe focused on one well-defined OCPI version helps keep both implementation and long-term maintenance under control, unless there is a strong need to support several versions directly.

One current limitation is the lack of an official and complete OpenAPI specification for OCPI. This is a known issue and is discussed here: ocpi/ocpi#228

From SteVe's perspective, OCPI can mostly be seen as a CRUD-style API with its own data model. Once the core concepts are mapped, it should be reasonably straightforward to implement on top of the existing backend.

In the JVM ecosystem, there are few actively maintained OCPI libraries. At the moment, I’m not aware of any that are both unopinionated and provide complete OCPI data models and HTTP interfaces.

One of the more solid options today is the IZIVIA OCPI toolkit: https://github.com/IZIVIA/ocpi-toolkit
It is opinionated by design and uses Kotlin, which makes it less suitable as a direct dependency inside SteVe if you want to keep the core as neutral as possible.
That said, it can work well as a separate project responsible for OCPI exposure, rather than being embedded directly into SteVe and mapped to SteVe’s existing APIs. In that case, some form of event or notification mechanism would likely be needed.

@lilgallon curious to hear if you see other JVM-based approaches worth considering.

[goekay]

I'll try to stay cautious regarding version coverage. From an architectural point of view, I would suggest starting with support for a single OCPI version rather than aiming for native multi-version support right away.
Supporting multiple OCPI versions usually adds a lot of complexity. In many ecosystems, this is handled by dedicated interoperability or translation layers (for example, ENAPI or similar services). Keeping SteVe focused on one well-defined OCPI version helps keep both implementation and long-term maintenance under control, unless there is a strong need to support several versions directly.

Fair enough, the focus is on 2.2.1 actually.

From SteVe's perspective, OCPI can mostly be seen as a CRUD-style API with its own data model. Once the core concepts are mapped ...

Yep, and I am trying to avoid exactly this type of grunt work to map these stubs and data models.

[juherr]

@goekay It looks like we share a similar hobby 🙂
You might enjoy this as well: https://ocpi.fyi/

[goekay]

very nice, what is the source of the openapi spec for ocp 2.3.0?

[juherr]

The initial source was generated by Claude based on the specification.
The plan is available in the repository.
I'm planning an update, as I’m not fully satisfied with a few details.
Once that's done, I'll move on to versions 2.2.1 and 2.1.1.

Let me know if you spot anything that could be improved.

[juherr]

@goekay openapi 2.2.1 is now available

[juherr]

@goekay fyi https://github.com/juherr/ocpi-doc/releases/tag/v0.1