| Re: [jnosql-dev] Move Eclipse JNoSQL forward as a JSR |
Hi all, I'd like to raise the question what you're expecting to achieve by making jNoSQL a standard *at this point in time*. There are a couple of issues that play into this: 1. I don't think the JCP / Oracle is even accepting new JSRs anymore. Everything was set to freeze with the handover to Eclipse. JakartaEE is currently busy with sorting out organizational issues, i.e. there won't be a release including any new JSRs and/or implementations before 2019 (whether that's a realistic time frame is debatable, too). 2. Making an open-source project a standard early in the project lifecycle will put all the burden of the standardization process onto the project, including very rigid constraints on the way you can evolve and change an API, but giving you what exactly? There won't be a a JakartaEE release incorporating in the immediate future, so why not use the time and mature the project a little? There's not even a 1.0 release yet. I think jNoSQL will hugely benefit from more real-world feedback as the recent discussion about terminology chosen shows. 3. There's quite a difference to the introduction of JPA back then. JPA was derived from years of experience of multiple implementations that were tackling the problem. No offense, but jNoSQL is basically an open-source project with an API JAR, that I haven't seen widespread adoption yet (admittedly, might be confirmation bias). Even more so, it's design incorporates design decisions that are antagonal to ones implemented in alternative approaches that have run in production for almost a decade. You of course need to take this with a gain of salt as I am the lead of Spring Data, but not every open-source project that has an API JAR should become a standard. Not because it shouldn't do so in general, but because at this point in time you risk it drowning in irrelevance as you're stuck between: "Well, that doesn't quite feel right, we'd actually like to change it." and "Ah, we can't change that because we need to stay backwards compatible." I can totally understand your desire to eventually standardize what you have, I just think the timing isn't right. Getting more involved with the Microprofile efforts might be a much better next step as it seems to be a very well working effort to eventually advance JakartaEE without being stuck in procedure and politics in the first place. Cheers, Ollie > Am 18.08.2018 um 23:41 schrieb Otávio Gonçalves de Santana <otaviopolianasantana@xxxxxxxxx>: > > > > > On Sat, Aug 18, 2018 at 4:53 PM Werner Keil <werner@xxxxxxxxxxx> wrote: > Otavio/all, > > > > There is one very important Thing you must clarify before considering a JSR after all. > > I don’t think many People doubt, JNoSQL should be part of the Jakarta EE platform in a similar way JPA does now? > > Given „old JSRs“ that were started before Java EE was archived and contributed to Eclipse via EE4J are good to use the „javax“ Namespace but any new specs aiming at Jakarta EE must not, I guess filing a JSR may end up as a „Standalone JSR“. > > > > > > When you proposed a JSR so far there was Always an Option of „Java SE“, „Java ME“ (also seems Pretty irrelevant now) and „Java EE“, the latter simply won’t exist and the only way to propose a new JSR now, is to be a „standalone JSR“ that is not meant to become part of a platform. > > The form that we have is the target, that means, there is not guaranteed this JSR belongs to any platform, please, check the JSR that we work as JSR 354 and JSR 363. > > I cannot say, if standalone JSRs could become part of the Jakarta EE platform unless they were files earlier and are good to use the „javax“ Namespace? > > After the process done in Jakarta EE you're right, however, it is not done yet. > > I’d be happy to ask the Specification Committee, but please also talk to People in the PMC or Steering Committee (Tomitribe/David should be in in most of those, so why not ask him) > > > Hey Werner, Yes, I did my homework and did the same question to several PMC and JCP-EC about it. There is not a unanimous answer to that. > You know the project history than everyone else here, the project was born on that transition that why we decided to wait for that time, but the current version is 0.0.6 and that is time to move the project forward. > > > > Werner > > > > > On Sat, Aug 18, 2018 at 6:00 PM <jnosql-dev-request@xxxxxxxxxxx> wrote: > Send jnosql-dev mailing list submissions to > jnosql-dev@xxxxxxxxxxx > > To subscribe or unsubscribe via the World Wide Web, visit > https://dev.eclipse.org/mailman/listinfo/jnosql-dev > or, via email, send a message with subject or body 'help' to > jnosql-dev-request@xxxxxxxxxxx > > You can reach the person managing the list at > jnosql-dev-owner@xxxxxxxxxxx > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of jnosql-dev digest..." > > > Today's Topics: > > 1. Re: Move Eclipse JNoSQL forward as a JSR (Werner Keil) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sat, 18 Aug 2018 00:57:07 +0200 > From: Werner Keil <werner.keil@xxxxxxx> > To: jnosql developer discussions <jnosql-dev@xxxxxxxxxxx> > Subject: Re: [jnosql-dev] Move Eclipse JNoSQL forward as a JSR > Message-ID: <0LeRKD-1gDnAn13e9-00qDWe@xxxxxxxxxxxx> > Content-Type: text/plain; charset="utf-8" > > Otavio, > > Thanks for the update, especially regarding Red Hat. > One Thing to Keep in mind, while Jakarta EE does not know a ?Reference Implementation?, instead it is called ?Spec Implementation?, which gives other implementations a slightly better Position, a JSR Needs a RI. > Should Red Had not only be happy to join a potential EG (which given its work with OGM would be very positive) but find consensus on where the RI was best done (Eclipse JNoSQL sounds logical, but of course other alternatives may exist) then it could be appealing. > > There still is no EDR for JSR 382. And when I last joined the call (while EG member I have other technological priorities and the call is a bit early in the day) the RI also seemed undecided. With nearly too many candidates like an Eclipse project or 2-3 Apache Projects. > > It may have been better to graduate the work at MicroProfile (which happens in parallel so the Project members and Spec Leads feel split between several code bases some of which used in a ?production? Environment and products of several Vendors already) and do it in Jakarta EE in this case judging from what?s going on, but I guess unless the JSR was voluntarily withdrawn it may also be in a Situation like CDI, Bean Validation or a possible NoSQL JSR if created. > > If it wasn?t for a Holiday Season, technically there should be a Renewal Ballot 1 for JSR 382, but Maybe you heard more About that in the EC? > > Luckily JNoSQL kept a rather low profile (except at conferences ;-) so far when it Comes to production use or inclusion in Commercial products, that could make it easier in either direction. > > So if some of the Questions like clarity About a RI can be answered and a ?Preproposal? for a JSR is appreciated by Major Players like Red Hat or Pivotal (see the GitHub tickets) and they may also join an EG, then why not, in this case the chances could be good. > > From: Ot?vio Gon?alves de Santana > Sent: Saturday, August 18, 2018 00:19 > To: jnosql developer discussions > Subject: Re: [jnosql-dev] Move Eclipse JNoSQL forward as a JSR > > Hey Werner, please remember several points: > > ? They will have weeks to start to talk about the package name, however, the process still not defined yet. > ? The first version of Jakarta EE will release just the Java EE 8 > ? The Jakarta EE 9 will release one year after the Jakarta EE be released > ? The Jakarta EE 9 may not include Eclipse?JNoSQL as a spec. > ? They can't ignore the project that is already defined?as javax.* > ? I really would like to move this project forward > ? The project is already in Eclipse Foundation. > > Yes, I sent an email to the Red hat guys and they would like to join us on this spec. > > > > > > > On Fri, Aug 17, 2018 at 4:08 PM Werner Keil <werner.keil@xxxxxxx> wrote: > I?m not sure, if this still makes sense now. > ? > It is only a matter of time, a few weeks now, before a Jakarta EE spec package Namespace is found or voted on. There are not many options. > Having to move back and forth or spread across two packages over time could irritate possible users. > ? > Several committers to Jakarta EE have never contributed to or joined the JCP. Especially now, it is even less likely they would participate or join an EG. > ? > Did you or could you ask e.g. Red Hat, if they would rather support JNoSQL in Projects like Hibernate OGM if it was a JSR than eventually graduating into Jakarta EE from where it is now? > ? > Red Hat also provides key parts of the Jakarta EE platform, that were not contributed to Jakarta EE and there is no sign, it plans to do in the near future. > ? > If the eventual Need to improve CDI or Bean Validation leads to new JSRs for CDI 3 or Bean Validation 3, then and only then I would consider filing a JSR. > Can you ask those at Red Hat in a Position to tell more About it? > ? > Werner > ? > From: Ot?vio Gon?alves de Santana > Sent: Friday, August 17, 2018 20:34 > To: jnosql developer discussions > Subject: [jnosql-dev] Move Eclipse JNoSQL forward as a JSR > ? > Everyone knows the new process to add new specifications in JakartaEE is not defined and without a date to be defined. We are working on the Eclipse JNoSQL to start the TCK and to support modules to be compliant with Java 9 and above. Therefore, at this moment the project needs either a process like the TCK and also the package definition. As the JakartaEE process is still not ready and JCP is still alive and mature, I would like to move the project forward and submit the JSR. This will allow us to have the "javax.nosql" package just like all the existing specs that I believe won't change the package in JakartaEE. > I would like to study that this weekend. > ? > Thoughts? > > ? > ? The proposal:?https://docs.google.com/document/d/17Zl4MzBgNnpf6o2VsPfFmidg_PxXljynm3kFHYUqKdA/edit?usp=sharing > ? Initial Contributor:?https://goo.gl/forms/tGRAAQFDWMAJXjVZ2 > -- > Ot?vio Gon?alves de Santana > ? > ? > twitter:?http://twitter.com/otaviojava > site: ? ??http://about.me/otaviojava > ? > ? > _______________________________________________ > 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 > > > > -- > Ot?vio Gon?alves de Santana > > > twitter:?http://twitter.com/otaviojava > site: ? ??http://about.me/otaviojava > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: <https://dev.eclipse.org/mailman/private/jnosql-dev/attachments/20180818/ae716dcd/attachment.html> > > ------------------------------ > > _______________________________________________ > 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 > > > End of jnosql-dev Digest, Vol 20, Issue 8 > ***************************************** > _______________________________________________ > 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 > > > -- > Otávio Gonçalves de Santana > > > twitter: http://twitter.com/otaviojava > site: http://about.me/otaviojava > > _______________________________________________ > 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
Attachment:
signature.asc
Description: Message signed with OpenPGP