User-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.6.1
If I am understanding it correctly, I think this is the right
move. The Repository portion should move to Jakarta Data. The
communication layer I don't think anyone will really use and
should be removed (I think hardly anyone sane uses plain JDBC).
The only thing that should remain here is the mapping/template
layer (similar to Jakarta Persistence).
On 1/11/2023 5:28 PM, Otavio Santana
wrote:
Hey Jesse and everyone.
I sent a message to some of you privately, and I got this
feedback.
My proposal would reduce the scope of the spec to focus
only on the higher-level API.
Note: for those who use JNoSQL it will change the package
name to "jakarta.nosql" removing the "mapping".
In my use, I've exclusively used the
higher-level Repository abstraction that will be moving
to Jakarta Data anyway, so NoSQL/JNoSQL itself is sort
of an implementation detail.
Still, it seems like there's value in having Jakarta
NoSQL as an intermediary spec in a similar vein to how
JPA will presumably act for that side of Data. Though I
imagine there's value in being in a Platform spec in
that it'd increase the odds of showing up by default in
app servers, being standalone makes sense in that most
apps wouldn't necessarily use a NoSQL backend. If it's a
smaller spec to the side that provides the thin plumbing
when you want to use Data with a NoSQL DB, that'd sound
fine.
I suspect there is some miscommunication here.
I would clarify whether multiple implementations
are really needed if this remains simply a
standalone specification.
Personally, I think more standalone
specifications and the Core Profile might be the
true future of Jakarta EE. There are things like
JCache that have long been a success in the
space simply being standalone.
On 1/11/2023 12:48 PM, Werner Keil wrote:
Mike/all,
+1 I also believe,
Jakarta NoSQL should stay with Jakarta EE,
not sure why there is another discussion or
idea of moving to MicroProfile?
For certain specs,
especially those building a Bridge to CNCF
Projects like OpenTelemetry, etc. or OpenAPI
it Looks fine and most MicroProfile Projects
may not benefit from a move to Jakarta EE,
but given that NoSQL is a sibling of Jakarta
Persistence, it seems odd having one sibling
here and another one at MicroProfile.
About the question of
platform/profiles, that is up to the
platform project, whether NoSQL shall be
included, but IMO the Full Platform could
very much Benefit from it, while e.g.
Jakarta Data could be suited for others even
the Web or Core Profile.
It’s a bit similar to
Jakarta MVC, whether that gets added to the
Web Profile or not seems open, Maybe it’ll
be an Optional standalone spec, but there
are other candidates for detaching it from
the platform, e.g. Pages (JSP) or Faces
(JSF) might become optional some day,
allowing to pick a particular stack like
Servlet/JSP/Faces
REST/MVC
And not be forced to
support multiple stacks.
Leaving aside the
optionality within Jakarta NoSQL (document,
Key-value, column or graph-based) the same
also goes if an application uses only
JDBC/JPA for relational databases or NoSQL
and depending on that technology choice they
require one or the other, so Jakarta
Persistence could potentially become
optional at least in say the Web Profile.
I don't
understand why having a second
implementation is a reason not to
include Jakarta NoSQL on the
platform. If you look at the
individual specs, most of them only
have one implementation listed.
I believe we
should remain on Jakarta EE so that we
have Jakarta Data, Jakarta NoSQL and
Jakarta Persistence all together.
From what I understand, Jakarta EE 11
is scheduled for 1Q2024.
Following
the previous feedback from the
program committee:
We
don’t have a problem with the
spec exploring this direction,
but we currently have no
interest in incorporating this
in any profile or the
platform. We’d also want to
see interest and active work
in a second implementation
before this spec would be
proposed final.
They
don’t plan to move it forward as
part of the Jakarta EE platform;
on the other hand, we have Jakarta
Data as a WIP specification that
takes considerable effort to make
happen.
Given
this scenario, what do you think
the best strategy for Jakarta
NoSQL is?
I
thought of some options:
Think
about moving to the Eclipse
Microprofile side
Returns
the efforts to focus on JNoSQL
(as a library that implements
Jakarta Data) and hold Jakarta
NoSQL for a while.
Find
a second implementation for
Jakarta NoSQL (which company?)