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?)