The Jakarta NoSQL's future

[otaviojava]

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.

jakartaee/specifications#506 (comment)

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?)
• Reduce the Jakarta NoSQL scope for only mapping annotations. It makes it easier for more implementations and vendors.

Another option, I'm open to suggestions.

[otaviojava]

I like the: "Reduce the Jakarta NoSQL scope for only mapping annotations"

[amoscatelli]

This is really sad, since NoSQL abstraction is really good.
I think it would fit Jakarta EE perfectly.

EDIT:
For the moment I'd stick with the second option (Jakarta Data) and continue working on Jakarta NoSQL till we have a final stable release.

And in any case NoSQL should keep on being tied to Jakarta and Microprofile specs as much as possible (good work with Jakarta Data and Jakarta Config !).

[arjantijms]

MicroProfile also isn't really eager to incorporate new APIs in the main platform it seems. There's quite a bunch of APIs at MP that are just like in EE separate ones (see e.g. long running actions etc).

Just a thought, but maybe we could opt for an "Extra profile" where all the extra APIs could go to (both the extra EE ones and the extra MP ones)?

[amoscatelli]

The "extra profile" seems like a really good idea to me.

[keilw]

Just a thought, but maybe we could opt for an "Extra profile" where all the extra APIs could go to (both the extra EE ones and the extra MP ones)?

That’s usually up to "Mix & Match" so not sure, what purpose a profile would bring, especially if all the standalone APIs plus MP (and who knows what else, e.g. Spring or something from CNCF) should go there, the possibilities and size would become endless.

I like the: "Reduce the Jakarta NoSQL scope for only mapping annotations"

Sorry Otavio, that you may suffer from a bit of an "Elon Musk syndrome" (trying to be involved in too many things at once) but ask e.g. Arjan, myself and others, there are several committers who have similar challenges trying to prioritize open source activities in multiple projects plus one or more customers/employees. The problem of optionality within the spec itself doesn’t go away if we threw everything in https://github.com/eclipse-ee4j/nosql/tree/main/api/communication out, there are mappings for column, document or key-value, too. Some of the *Query features in the communication modules might end up in Jakarta Data, so do many of the "mapping-core" elements like Repository or Template. Even in Jakarta Data there’s a likely variety of NoSQL with different types vs. JDBC/JPA, but that is the most compelling reason why keeping Jakarta NoSQL here, to serve on top of Data somewhat similar to e.g. the relationship between Jakarta JSON-P and JSON-B ;-) If we wanted to speed things up or descope some lesser used parts, why not look at a popularity rank like: https://db-engines.com/en/ranking There are no pure column-based systems within the top 10, so why not leave them out for now, stick to document and key-value, we get graph for free via Tinkerpop. And if vendors like Amazon, Microsoft or users/providers of Cassandra really want support for their column-based Solutions, they better get involved and help us doing that in v 2.0 of Jakarta NoSQL. Werner Von: Arjan Tijms Gesendet: Donnerstag, 12. Januar 2023 14:34 An: eclipse-ee4j/nosql Cc: Subscribed Betreff: Re: [eclipse-ee4j/nosql] The Jakarta NoSQL's future (Issue #153) MicroProfile also isn't really eager to incorporate new APIs in the main platform it seems. There's quite a bunch of APIs at MP that are just like in EE separate ones (see e.g. long running actions etc). Just a thought, but maybe we could opt for an "Extra profile" where all the extra APIs could go to (both the extra EE ones and the extra MP ones)? — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[otaviojava]

On the e-mail list, we decided to move forward with the stable parts on the spec side, and everything else on the JNoSQL implementation.