There are several bodies like the Steering or Spec Committee as well as EMO (the Eclipse Specification Document also shows a draft on the life-cycle) that are involved in approving a new spec.
Several of these documents and processes are not in place yet, so these approvals cannot happen right now. It is everyone's intent to give projects like JNoSQL, maybe a few others (like JSR 382/MicroProfile Config or a few other sub-components under MicroProfile) the chance because they already are Eclipse projects and therefore embrace enough of the "code first" attitude Jakarta EE hopes to support more than at least some of the earlier standards developed in the JCP.
Most importantly, there will not be a "new JSR" for Jakarta EE. CDI, Bean Validation and maybe a few legacy ones like MVC, probably JCache are the only ones, that are not directly under Jakarta EE right now.
A few like MVC (after the RI project was renamed) could go there, it is fairly advanced with a Public Review out, so a 1.0 release is still expected to be a JSR. Based on Jakarta EE rulings there must not be new code in the "javax" namespace after that. The Maven groupId changes immediately for all Jakarta EE artifacts. And if I don't know, Enterprise Security 1.1 went along and introduced a "SecurityListener" then it must do so under the new package jakarta.enterprise.security.
JSR 382 has never published anything to MavenCentral, it is a bit of a Zombie case and I saw, Mark got a JavaLand session about it but JavaLand does its CFP terribly early, so sometimes talks are no longer relevant when it starts next year ;-/
As there is no EDR unlike MVC, it probably would be good to also migrate it, but that is not up to this group to decide.
JNoSQL is happy to do this migration whenever it is invited to do so. There is also no 1.0 release or something that companies would use in production in good faith. The 0.0.6 release so far in MavenCentral can be seen as "Alpha" but jut take JSR 310, it was at least tagged under "javax.time" for ages till around Public Review before it was added to the Java SE platform, so no real harm here and org.jnosql is not a standard or spec like "javax" or "jakarta".
So if you want it's a bit like "org.springframework" which in some cases picks up JSRs like 330. Yet keeping the old proprietary annotations like @Autowire forever next to standard-compliant ones like @Inject.
By not creating a JSR and going straight to Jakarta, we avoid that, there will be no org.jnosql after a certain release ;-)
Werner
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: JNoSQL and Jakarta EE (Oliver Gierke)
----------------------------------------------------------------------
Message: 1
Date: Mon, 24 Sep 2018 20:43:18 -0400
From: Oliver Gierke <ogierke@xxxxxxxxxx>
To: jnosql developer discussions <jnosql-dev@xxxxxxxxxxx>
Subject: Re: [jnosql-dev] JNoSQL and Jakarta EE
Message-ID: <A91C2917-19D6-4B9A-8A3F-924CD1216970@xxxxxxxxxx>
Content-Type: text/plain; charset="utf-8"
> Am 24.09.2018 um 17:54 schrieb Ot?vio Gon?alves de Santana <otaviopolianasantana@xxxxxxxxx>:
>
> Please, check the thread "Move Eclipse JNoSQL forward as a JSR" I put the meeting backlog there from Jakarta EC such as the David Blevins doc from the package definition that uses the Eclipse JNoSQL itself, Mike Milinkovich decision to move forward with new proposals.
That's a discussion on this list here which is not really a authorative place to decide about upcoming JSRs is it? Also in the documents [0] Werner linked, I only found general discussions about namespaces and JNoSQL being *considered a candidate to first follow the new process*. That's by far not in the ballpark of what the post is suggesting.
> I also explained on the JCP-EC meetings about the decision to wait for the Jakarta EE process.
That's fine. However that does not conclude anything, does it?
> Yes, to be honest, I did not think about it when I wrote. Usually, I write an article from Dzone, JaxCenter or any platform then request to append it as "Community news" in the Eclipse Foundation section. I'll push this feedback.
It casts a pretty bad light on both the vendor and the Jakarta EE process in general as it creates the impression that which new JSR are to be pursued is not decided by an elected committee following a prescribed process but anyone who decides he wants to do that and ends up publishing that fact in a blog post framing it as blessed decision.
> https://docs.google.com/document/d/1wulckg85DQPGy7vGVlsWhw4H041q-ju5RD-HoYaoqMw/edit?ts=5b871208#
To quote from that document:
> Recruit our first candidate spec willing to announce their interest in using the Jakarta EE spec process. Eclipse JNoSQL was discussed as one potential.
With that JNoSQL is *discussed* as *potential candidate* to announce interest to be willing the new spec. That's not at all what the blog post says. That implies that there has been a formal decision (by the Jakarta EE working group / spec committee) that there will be a NoSQL JSR, which in fact has not been made (yet).
The Eclipse Foundation Specification Process v1.0 document [1] is pretty clear about the way a new specification gets created. It needs the approval of the supermajority of the steering committee (see "Approvals"). Such a vote has not been held yet.
I can totally understand that you're eager to get started. However, you need to understand that someone singlehandedly announcing stuff lack that in a vendor blog post undermines the trust in the way Jakarta EE is governed. We've already had the JCP suffer from problems like these. Let's not repeat that mistake in Jakarta EE.
Cheers,
Ollie
[0] https://docs.google.com/a/eclipse-foundation.org/document/d/1wulckg85DQPGy7vGVlsWhw4H041q-ju5RD-HoYaoqMw/edit?disco=AAAACHCidzI&ts=5b871208&usp=comment_email_document
[1] https://docs.google.com/document/d/1M51ZXlvCNS_X23OZupPs34pbkOuTPxKryZC0buA_smE/edit#heading=h.pmjougscf7ap
>
> > Am 24.09.2018 um 13:28 schrieb Ot?vio Gon?alves de Santana <otaviopolianasantana@xxxxxxxxx>:
> >
> > Congratulations to us, we'll be the first specification at Jakarta EE in the history.
> >
> > https://www.tomitribe.com/blog/jnosql-and-jakarta-ee/
> >
> > --
> > 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
>
> _______________________________________________
> 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/20180924/426f108a/attachment.sig>
------------------------------
_______________________________________________
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 21, Issue 8
*****************************************
