| Re: [jakartaee-platform-dev] [DISCUSS] Include Jakarta Data in EE 11 |
Hi, as explained in other replies already, I didn't intend to give an exhaustive rationale on the decision. I wanted to clarify that the assumption we'd implement the spec was invalid. Primarily because I was surprised that someone would actually even assume that. There are other aspects and design decisions that we think are problematic from a API user's point of view (CrudRepository returning Streams, Keyset scrolling intermingled with pagination etc.) but I think that discussion is to be had on a different channel. I also think that the discussion here is a bit backwards at this point. Scott gave a few arguments on why RedHat opposes the decision (I don't even have the power to vote on anything). I don't necessarily agree with their position but still think that it is one that can be reasonably argued. So for us (Spring Data) the actual question is not why would not want to implement the specification, but *why* we would want to in the first place. And as things stand right now, there's simply no incentive and we have to carefully evaluate what stuff we actually spend time on, as we're pretty busy even in a world without Jakarta Data :). Let's zoom out back to the original topic: the discussion whether or not to include Data in Jakarta EE 11. With the point I tried to make being made now, I'll refrain from further commenting on that, because I think it makes more sense for parties with actual voting power to share their opinions. Happy to discuss more technical details in more appropriate channels. Cheers, Ollie > On 13. Jul 2023, at 15:54, Nathan Rauh via jakartaee-platform-dev <jakartaee-platform-dev@xxxxxxxxxxx> wrote: > > !! External Email > Oliver, > I hope the following comment that you posted is just a misunderstanding of what has actually gone into the spec vs. what was under discussion but not actually included, > > In other words: the problem we see is not the lack of features but the scope already exceeding what's been established in the industry. This would add more complexity to our projects with no apparent benefits. Given the current state of affairs there are no plans for Spring Data to implement the specification. > Regarding the instances you cited of exceeding what vendors currently do: > https://github.com/jakartaee/data/issues/109 - It’s true this would have been a major addition that exceeds what vendors do. It was discussed a lot. It was very contentious with a lot of disagreement over it. Consequently, it never went into the spec. This should not in any way be blocking Spring from implementing Jakarta Data because this proposal isn’t part of Jakarta Data. > https://github.com/jakartaee/data/issues/94 - This one confuses me because it’s just an extra annotation that does exactly the same thing that the OrderBy keyword already does, and I can’t see how something so trivial could cause trouble to Spring Data. Hopefully the real reason was the mistaken belief that 109 had gone into the spec, not this change. There was certainly disagreement on whether this annotation should be taken out of the spec that went on for some time, I thought we had ultimately resolved it on one of the Jakarta Data calls, which included both Graeme and Otavio (apparently no one from Spring must have been on that particular call). If this truly does somehow block Spring from implementing Jakarta Data, or if Spring just feels so strongly about it that you would forgo implementing Jakarta Data over it, then we’ll just take it out of the spec for you. Please follow up with me on that (either one this email chain or separately) and we’ll get it taken care of. > From: jakartaee-platform-dev <jakartaee-platform-dev-bounces@xxxxxxxxxxx> on behalf of Oliver Drotbohm via jakartaee-platform-dev <jakartaee-platform-dev@xxxxxxxxxxx> > Date: Thursday, July 13, 2023 at 8:40 AM > To: jakartaee-platform developer discussions <jakartaee-platform-dev@xxxxxxxxxxx> > Cc: Oliver Drotbohm <odrotbohm@xxxxxxxxxx> > Subject: [EXTERNAL] Re: [jakartaee-platform-dev] [DISCUSS] Include Jakarta Data in EE 11 > Hi, > > > On 13. Jul 2023, at 13:47, Werner Keil via jakartaee-platform-dev <jakartaee-platform-dev@xxxxxxxxxxx> wrote: > > > > You keep speaking "for Micronaut" and Graeme, … > > I don't. I was referring to tickets in which he expressed the same concerns as we did (links included in the original message). That certainly doesn't mean the Micronaut team can't come to a different conclusion. > > I am not even arguing technical direction (anymore). All I was trying to do is clarify on the assumption that Spring Data would plan to implement the specification. And I thought I'd share a few details why that is. > > > Why don't you try the same? > > What exactly? Take part in the discussion? That's what we do / did, as is apparent from the tickets I linked. > > Cheers, > Ollie > > !! External Email: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender._______________________________________________ > jakartaee-platform-dev mailing list > jakartaee-platform-dev@xxxxxxxxxxx > To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
Attachment:
signature.asc
Description: Message signed with OpenPGP