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.
Werner
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.
https://github.com/jakartaee/specifications/pull/506#issuecomment-1286781992
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?)
Another
option, I’m open to suggestions.
--
_______________________________________________
nosql-dev mailing list
nosql-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/nosql-dev
--
Code,
Test, Write, Cycle,
Run,
Drink,
Sleep
...
Repeat
Lead
Java Queue Editor, InfoQ
Laissez
Les Bon Temps Rouler
he/him/his