| Re: [jnosql-dev] JSR scope |
If there are no dependencies to the full Java EE stack it could be beneficial, but except for a „serverless runtime“ I see a vast majority of use cases in a Server or „Cloud“ Environment, not so much on Desktop or Mobile/Embedded.
Whether or not there could be synergies with existing APIs like JPA, Bean Validation or others we’ll see.
Especially Bean Validation sounds tempting, but it too does not have other mandatory Java EE dependencies and can be used e.g. in a Rich Client app using Swing, SWT or JavaFX.
Do you have draft for a possible future JSR proposal?
Which one is supposed to be the RI, Diana-Driver only?
More or less anything other than a possible JSR API if approved would all go to Eclipse, correct?
Artemis more or less makes the Impression of JPA on top of Java SQL APIs. I cannot say if this functionality wasn’t an Overkill for Microprofile as a whole, but e.g. some extensions (like the „Artemis-extension“ module) certainly could make sense, as OPTIONAL modules (this is nothing to make mandatory, neither relational nor non-relational DB should be)
So let’s first get it moved to Eclipse and see how e.g. MP evolves over time. Should it emerge to have real subprojects or even something like a WG/TLP then maybe, but there are also other Areas at Eclipse like EclipseLink dealing with ORM and DB Access already, so I would not nail it down to either at this Point.
Werner
Sent from Mail for Windows 10
From: Otávio Gonçalves de Santana
Sent: Wednesday, March 22, 2017 19:36
To: jnosql developer discussions
Subject: [jnosql-dev] JSR scope
My original idea:
1)The proposal to JSR has a target to just Java SE. This objective just will involve the communication layer, aka Diana.
2)Work for two years on this JSR (contact layer).
3) Final release
4) Start to work more with Artemis to improve the JSR
In parallel submit the Artemis project as MicroProfile project.
The feedback:
* Delivery just communication seems an incomplete feature
* In a JSR we can have put both targets, so why not do this way?
* Wait four years a complete feature to NoSQL does not seem a good deal.
Following these feedbacks:
I'm changing my mind and in the first version of the JSR to already have the two layer (communication and abstraction layer). Even we do not believe everything at the first release, which seems interesting to the Java Community.
So:
1) Start the proposal JSR with both target Java SE and Java EE
2)Work for two years on this JSR (both layer)
After the release delivery planning a new version with more feature to the next JSR version.
My question is:
What do you guys think about that?
Does it make sense?
Any feedback is welcome.
--
Otávio Gonçalves de Santana
_______________________________________________
jnosql-dev mailing list
jnosql-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jnosql-dev