Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jnosql-dev] [nosql-dev] The Jakarta NoSQL's future

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

 

Von: Michael Redlich
Gesendet: Mittwoch, 11. Januar 2023 17:35
An: nosql developer discussions
Cc: jnosql developer discussions
Betreff: Re: [jnosql-dev] [nosql-dev] The Jakarta NoSQL's future

 

Hey Otávio:

 

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,

 

Mike.

 

On Wed, Jan 11, 2023 at 4:35 AM Otavio Santana <otaviopolianasantana@xxxxxxxxx> wrote:

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.

 


--

Otávio Santana

_______________________________________________
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

 

Back to the top