[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [jakartaee-platform-dev] [DISCUSS] Include Jakarta Data in EE 11
|
Hibernate was also dominant in the Relational DB access,
Persistence and OR-Mapping, yet JPA was established and Hibernate
eventually implemented it.
Can't speak for DeltaSpike, because Apache does not specify
things, it implemented several Jakarta Specs in the past, JSP
(Tomcat) or JSON Processing, it even implemented JPA, but OpenJPA
did not seem active after 2021 anymore, ironically missed the
Jakarta EE train for some reason.
For many there is a sandbox, it's called MicroProfile. There were
also ideas to get Data started there, but at least the whole
evolution and journey of Jakarta Config (starting largely
influenced by DeltaSpike, then via a brief intermezzo at Apache
Tamaya went into MP Config, then JSR 382 before becoming Jakarta
Config) made that seem more hindering than improving.
DeltaSpike is as dead as OpenJPA, the last update to its main
entry page was 2021, most other pages even stopped changing in
2016, referring to Java SE and EE 6.
There are newer frameworks now like the mentioned Quarkus,
Micronaut or Helidon.
Regards,
Werner
On 13.07.2023 12:09, hantsy bai via
jakartaee-platform-dev wrote:
As stated before, I hope Jakarta starts a sandbox project
or so called Jakarta umbrella project(as a sister project of
the spec projects) to hand over Jakarta Data, Apache
DeltaSpike, etc to ease the Jakarta EE development.
* Personally I do not think the Repository pattern can be
defined as spec, Spring Data, Micronaut Data, Quakrus has its
own way to cook Repository, but it is good as a tooling
project to extend existing Jakarta EE spec.
* A lot of Apache Deltaspike features are useful, but they
are not updated, local transaction, type safe config, type
safe resource boudle(for Faces, Validator, etc.), message CDI
event bridge ...
Hi
all,
> On 13. Jul 2023, at 05:09, Edward Burns via
jakartaee-platform-dev <jakartaee-platform-dev@xxxxxxxxxxx>
wrote:
>
> Nathan Rauh wrote: … 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.
the expectation of Spring Data ending up implementing the
standard is unfounded. we (the Spring Data team) and also
Graeme of Micronaut have repeatedly expressed concerns [0, 1]
regarding the spec going far beyond what's currently
established introducing new features that have no basis in
real-world user needs or are at least not validated in an
implementation.
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.
Cheers,
Ollie
[0] https://github.com/jakartaee/data/issues/94#issuecomment-1416864983
[1] https://github.com/jakartaee/data/issues/109#issuecomment-1380230020
_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev