|Re: [jnosql-dev] [nosql-dev] The Jakarta NoSQL's future|
+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
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.
All the best,
On Wed, Jan 11, 2023 at 4:35 AM Otavio Santana <otaviopolianasantana@xxxxxxxxx> wrote:
Back to the top