Re: [jakartaee-platform-dev] Optional parts of a Spec or a "Bridge"

[Ondro Mihályi <mihalyi@xxxxxxxxxxx>]

In my opinion, ideally, no spec should strictly require any other spec unless it builds the API on top of another spec’s API (like MVC builds on top of REST API). If some specs are likely to be used with other specs, then they should specify how the specs work together if they are integrated in the same container/app. 

In case of Jakarta Data and Persistence, if Data API doesn’t require APIs from Persistence, it should be possible to build an implementation that just passes the Data TCK and not Prrsistence TCK.

 If the implementation implements both, then it should pass also the part of the TCK that tests their integration.

a) I wouldn’t force any spec to depend on another spec if their integration is optional and runtimes don’t need to implement both

b) I wouldn’t invest rhe effort into creating a separate bridge spec to cover an integration of 2 specs. It would introduce way too many specs, for each combination of specs that can integrate together

c) Platform or profile specs may cover integration of specs but I would’t rely on that. In practise, this rarely happens because these specs have a different committer team and a different focus. And 2 specs like Data and Persistence can be available in a single runtime which still doesn’t implement full platform or a profile. So it’s better to cover the integration in one or the other spec (in this case I’d say it should be in the Data spec)

Ondro

On Sat, 2 Sep 2023 at 14:50, Arjan Tijms via jakartaee-platform-dev <jakartaee-platform-dev@xxxxxxxxxxx> wrote:

Hi,

On Fri, 1 Sept 2023 at 23:28, Emily Jiang via jakartaee-platform-dev <jakartaee-platform-dev@xxxxxxxxxxx> wrote:

Maybe CDI EE bits should go to web profile or platform instead of creating a dedicated spec. In this way, the umbrella tcks for Web Profile and Platform are for integration tests.

If I read the current chapter about EE: https://jakarta.ee/specifications/cdi/4.0/jakarta-cdi-spec-4.0#part_3

Then the integration chapter / sub-spec / potential demand on the platform, would be much smaller if:

1. The build-in beans would become the responsibility of the specs that own the artefacts in question. Specifically https://jakarta.ee/specifications/cdi/4.0/jakarta-cdi-spec-4.0#additional_builtin_beans would not be needed at all.

2. Enterprise Beans would be rebased as an extension for CDI. That way things like https://jakarta.ee/specifications/cdi/4.0/jakarta-cdi-spec-4.0#default_bean_discovery_ee would not be needed anymore. Most of that, and other sections like it, are about Enterprise Beans.

As alternative to 2, we move all of the Enterprise Beans integration concerns to the Enterprise Beans spec.

Kind regards,

Arjan Tijms

 

e earlier, that certifying for Data was too hard, what if they need to certify against Persistence as well, even if they don't use relational databases.

Take Apache Johnzon: https://johnzon.apache.org/download.html which while still calling it "JavaEE 10" hopes to pass the TCKs of Jakarta JSON Processing and Binding. Another project could also decide to implement just JSON Processing, it is not forced to implement or support both.

Werner

 

_______________________________________________
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

_______________________________________________
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

--

Thanks
Emily

_______________________________________________
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