Hi, Yes, that also reflects what I heard in the Jakarta Specification Committee yesterday evening. „javax“ is not illegal to use per se, unless Oracle stopped the JCP as a whole, but for „Platform Standards“ like Jakarta EE the aim is, to give every new non-final spec a new Namespace, presumably „jakarta“ (that is still to be confirmed) While I am not in the EC at the Moment, what was mentioned yesterday also sounds like the Config JSR which was filed before that, but has not even produced an EDR yet (after that would be due per JCP.next) nor any artifact on MavenCentral under the „javax.config“ namespace could be withdrawn by Eclipse, voted down by the EC (if a formal Renewal Ballot must be Held) or something inbetween. IMO it could be a clean slate here, too. The prospect of a „Java SE Mode“ without CDI is probably still worth to Keep, so e.g. Spring may support it like it also does with Jakarta EE, but that does not mean, it has to be a JSR either. Others that are purely standalone like VisRec (this can be used in Desktop apps, on Mobile Devices or in the Cloud) or Unit-API (ditto, works from Edge Devices to Big Data in the Cloud) won’t be affected and as Long as the JCP exists under the current Terms, those JSRs may continue to use „javax“. Werner Sent from Mail for Windows 10 Based on the previous comments I did one more round of questions to a lot of JCP-EC and PMC from Jakarta EE. - It seems the "javax" namespace might be a legal issue in the future.
- They're pretty close of finish the Jakarta EE process.
- Eclipse JNoSQL is a strong candidate to run on the new Jakarta EE process.
Olli/all, Thanks for the input. It largely echoes doubts I had and mentioned here over the weekend. Like Hibernate for Relational Databases helped inspire JPA, Hibernate OGM could and should be taken into consideration, whether under the EE4J umbrella or elsewhere. I see no sense to simply move JNoSQL from a separate project under the "Technology" umbrella into the "shark pool" of MicroProfile. As seen with Config and a few other cases (e.g. the REST proxy) those involved as project or spec leads have a hard time keeping up all their efforts and the Config JSR is behind schedule based on JCP.next expectations and guidelines. Because there are other duties and responsibilities they got in MicroProfile "features". There are no clear sub-projects therefore the whole versioning is messy and with a so far active version cycle JNoSQL would even make that worse. Plus MicroProfile aside from a few dedicated glue projects for other external systems and ecosystems looks very much like a collection of popular Microservice patterns from: https://microservices.io/index.html A kind of "GoF equivalent" in the Microservice space. There are a couple of Data related patterns like https://microservices.io/patterns/data/database-per-service.html or "Saga". Which could find support in another MicroProfile feature or multiple, but neither of these patterns mandate that you have to use relational databases, plain file stores or NoSQL databases. That would be counterproductive. Which is why JNoSQL could be used to support some of these patterns, but I see no reason why JNoSQL should move to MicroProfile rather than EE4J, that is where it should be aim for when the time comes.
Yes, that was the same conclusion that I had, that why I would submit into a JSR process. 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 (Oliver Gierke)
2. Re: Move Eclipse JNoSQL forward as a JSR
(Ot?vio Gon?alves de Santana)
----------------------------------------------------------------------
Message: 1
Date: Mon, 20 Aug 2018 10:32:50 +0200
From: Oliver Gierke <ogierke@xxxxxxxxxx>
To: jnosql developer discussions <jnosql-dev@xxxxxxxxxxx>
Subject: Re: [jnosql-dev] Move Eclipse JNoSQL forward as a JSR
Message-ID: <CA4FE3BE-A5DD-4030-9B74-6C793D773603@xxxxxxxxxx>
Content-Type: text/plain; charset="utf-8"
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <https://dev.eclipse.org/mailman/private/jnosql-dev/attachments/20180820/32311231/attachment.sig>
------------------------------
Message: 2
Date: Mon, 20 Aug 2018 08:56:13 -0300
From: Ot?vio Gon?alves de Santana <otaviopolianasantana@xxxxxxxxx>
To: jnosql developer discussions <jnosql-dev@xxxxxxxxxxx>
Subject: Re: [jnosql-dev] Move Eclipse JNoSQL forward as a JSR
Message-ID:
<CAPc8kR0ADNaPk8HrQXCU6psTjPrybJDxhjtV4oy4WOKvVtbhmw@xxxxxxxxxxxxxx>
Content-Type: text/plain; charset="utf-8"
On Mon, Aug 20, 2018 at 5:33 AM Oliver Gierke <ogierke@xxxxxxxxxx> wrote:
> 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).
> Yes, JCP still alive and ready to receive any JSR that we want to submit.
> Currently, there are a couples JSRs in WIP.
>
> 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.
>
A JSR has a lifecycle, that means after the submission the project does
not become a standard. That means the project is ready to begin the journey
in standard in the Java world.
https://jcp.org/en/procedures/overview
There is JSR such as JCache that take more than ten years to be ready,
also the JSR 377 <https://jcp.org/en/jsr/detail?id=377>
What I have in mind is to release a 1.0 version with a proper
nomenclature. Otherwise, we'll release a version 1.0 with the package name
"org.jnosql.*" then break the version again to "jakarta.ee.nosql",
"javax.nosql" or any package name definition.
>
> 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."
>
> Yes, these are fair points and very interesting ones. But one important
> point. The JSR will be released as final when we feel that is ready to be
> final until there we can break every single time. Usually, a JSR starts
> from the scratch such as CDI 1.0 <https://jcp.org/en/jsr/detail?id=299>
> that took around three years to become ready, thereby have a bunch of APIs
> that we can break IMHO: that is more than enough to start that discussion
> with the JCP and the lifecycle as a JSR.
> 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.
>
About the integration between Microprofile and JNoSQL, we had this
discussion in the past
<https://groups.google.com/forum/#!topic/microprofile/Uy-TwXuCEaM>. We
agreed that is not the scope of Microprofile, however, we can raise the
discussion again.
I hope now it becomes cleaner, but I won't define what I have as standard I
would like to start the JSR process, for example, it will take the
necessary time as any JSR.
>
> 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
>
> _______________________________________________
> 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 <http://about.me/otaviojava>*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://dev.eclipse.org/mailman/private/jnosql-dev/attachments/20180820/78970b33/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 10
******************************************
_______________________________________________
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
-- Otávio Gonçalves de Santana |
