|Re: [jakartaee-platform-dev] Optional parts of a Spec or a "Bridge"
It’s good to know how to handle this situation if it becomes necessary.
There are a lot of discussions and new ideas being brought up in Jakarta Data. Many of them may end up being brought into Jakarta Data in one form or another, but the API currently has no dependency on Jakarta
Persistence. The specification document and JavaDoc currently reference Jakarta Persistence just as they reference Jakarta Validation and other Jakarta specs (and even Jakarta NoSQL) to state requirements for interoperability but that sort of thing is typical
of Jakarta specifications. Unless changes to the API are actually approved that require Jakarta Persistence – and at this point I’m not yet convinced that much will be needed – creating a bridge specification seems like getting ahead of ourselves.
Kyle has done excellent work with the TCK and it does not require the Jakarta Data provider to be backed by Jakarta Persistence, although some extra tests to validate Jakarta Persistence-related requirements
will run if it is. The TCK even has a mode for running in core profile (where there is no Jakarta Persistence) although Jakarta EE 11 is not targeting core profile for Jakarta Data.
To ensure the cleanest separation of dependencies at both the API and TCK level this can be done in a separate bridge spec with separate artifacts, but this should
be produced by the Jakarta Data project with collaboration with Jakarta Persistence
To ensure the cleanest separation of dependencies at both the API and TCK level this can be done in a separate bridge spec with separate artifacts, but this should be produced by the Jakarta Data project with
collaboration with Jakarta Persistence project members. This should be done concurrently with the Jakarta Data 1.0 spec.
On Fri, Sep 1, 2023 at 9:33 AM Steve Millidge (Payara) via jakartaee-platform-dev <jakartaee-platform-dev@xxxxxxxxxxx> wrote:
Back to the top