Hello,
After Jakarta Data was just successfully accepted to the Full and
Web Profile, it is equally important for users of the Core Profile
who want to use repositories and other features with the database
of their choice, either NoSQL or SQL/JDBC/JPA based.
However, there is desire by some in the Persistence camp, to
force Jakarta Persistence as a mandatory dependency onto Jakarta
Data, see
https://github.com/jakartaee/data/pull/235
Or
https://github.com/jakartaee/data/issues/229
Which is where I also made this remark:
There are 3 options where these "implementations" or
specializations could happen:
* In actual implementation modules, much like spring-data-jpa or micronaut-data-jpa do now
* In Jakarta Persistence as a downstream spec
* In a "Bridge" spec between Data and Persistence, a bit like the Portlet Faces Bridges defined by the JCP or the bridging efforts between Jakarta Security and Microprofile
A 4th option is currently not realistic, it would
require optional sub-modules that depend on Jakarta
Persistence/JPA etc. but Jakarta EE right now only knows
"optional" for features to be phased out soon.
Although the Core Profile under 2.2. Optional
Components already defined some specs that are optional for that
profile, so the question is, would it be possible to do this on a
detail spec level, or does such a spec need a "bridge" or another
separate spec like "jakarta-data-persistence"?
Frameworks like Spring Data or Micronaut Data use JPA only in
sub-modules that are more an implementation than spec/API, but of
course they are no specs to begin with, so it is easier for them.
I believe, the adoption of Jakarta Data will suffer if
JPA is forced down the throat of every Jakarta Data use case,
whether it's NoSQL or other non-relational usage of the spec.
And let's not forget those who complained here
earlier, that certifying for Data was too hard, what if they need
to certify against Persistence as well, even if they don't use
relational databases.
Take Apache Johnzon:
https://johnzon.apache.org/download.html which while still calling
it "JavaEE 10" hopes to pass the TCKs of Jakarta JSON Processing
and Binding. Another project could also decide to implement just
JSON Processing, it is not forced to implement or support both.
Werner
_______________________________________________