Skip to main content

[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

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 ...

---

Regards,

Hantsy Bai

Self-employed consultant, fullstack developer, agile coach, freelancer/remote worker

GitHub: https://github.com/hantsy

Twitter: https://twitter.com/@hantsy

Medium: https://medium.com/@hantsy


On Thu, Jul 13, 2023 at 5:27 PM Oliver Drotbohm via jakartaee-platform-dev <jakartaee-platform-dev@xxxxxxxxxxx> wrote:
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

Back to the top