Hello Platform Dev,
I have attempted to capture prior
discussion about this topic from the following sources:
- Agendas: Previous agenda google docs
-
GitHub Issue: The corresponding issue
in
https://github.com/jakartaee/jakartaee-platform/issues.
-
Platform-dev Archive: Any mails on
the archive at
https://accounts.eclipse.org/mailing-list/jakartaee-platform-dev.
-
Agendas
2023:
-
Will run a
formal vote on the mailing list to decide whether to
include or not later
-
Target profile
start: web?
§
Inclusion
history
·
First
time at the gate
·
Spring
Data similarity. Layer on top of JPA.
§
Data
does define a number of aspects of platform integration.
§
Jan
shared some aspects of Spring Data vs. the way Jakarta Data
is proceeding.
·
There
was some disagreement about the extent to which the Data
team did reach compromise.
-
GitHub Issue
https://github.com/jakartaee/jakartaee-platform/issues/640
Hantsy wrote:
I have
used Microaunt Data and Spring Data in projects, compared to
these existing Repository solution, I think Jakarta Data
needs more time to enter the Jakarta main release train.
Currently in Jakarta EE 10, we lack reactivestreams(or Java
9 Flow) and context propagate support in the core specs,
such as http, cdi, tx, etc. Jakarta EE 11 discussion leaves
some room for the common spec, we could consider these.
Personally I like the idea, and I would like to use all
akarta EE specs seamlessly like using Spring in the
application development, not spend time researching the gap
between specs. I am not sure if the Jakarta Data 1.0 will
include async, and reactive streams( or Java 9 Flow API)
support and if they(eg. Java 9 Flow) are supported in other
spec(servlet, faces, rest).
Scott
Stark wrote:
Red Hat will vote no on its inclusion. It needs more bake
time in implementations.
Werner Keil wrote:
@starksm64 Hopefully
Red Hat also finds the time to participate as other provider
reps do, especially given its mother company IBM co-chairs
the spec? ;-)
Whenever it's considered
ready (hopefully by Jakarta EE 12) I would not outrule the
Core Platform either, but at least Web sounds fine.
Nathan Rauh wrote:
For all
of those who have already decided on a No vote this early
on, I'd like to collect your feedback about what is lacking
from the 1.0 release of Jakarta Data. (Thank you @hantsy for
pointing out that you want to see Reactive/Flow included).
We still have 6 months of spec development timeframe at this
point, and if you have concerns or specific requirements, it
might be possible to add what you believe is lacking to
version 1.0. Over-generalized statements that the
specification lacks maturity are not particularly helpful
and are somewhat confusing given that the established
products (Spring Data and Micronaut) are expected to become
implementations of Jakarta Data. It would be much more
helpful to know exactly what from Spring Data and Micronaut
that the Jakarta Data spec hasn't already standardized that
you would like to see included.
Scott
Stark wrote:
This
spec is largely a copy of the Spring Data repository effort,
and this is not something we fundamentally agree with. We
advocate a active record pattern to our users in our
products, so fundamentally we disagree with this spec as a
general approach for any profile or platform. Given that
these cannot have an optional specification, the data spec
would have to be getting traction in other EE
implementations and generating user interest before we would
consider this for a profile or platform.
Nathan Rauh wrote:
Involvement from RedHat to help shape the specification
would certainly be welcome. Its current focus on unifying
Spring/Micronaut/JNoSQL follows from the contributions of
participants.
-
Platform-dev Archive: I could not
find any discussion in the archive. There may be
discussion, but I could not find it. Anyone with better
search skills please do provide links.
|
edburns@xxxxxxxxxxxxx | office: +1 954 727 1095
|
Calendar Booking:
https://aka.ms/meetedburns
|
|
Please don't feel obliged to read or reply to this e-mail
outside
|
of your normal working hours.
|
|
Reply anonymously to this email:
https://purl.oclc.org/NET/edburns/contact