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

[Nathan Rauh <nathan.rauh@xxxxxxxxxx>]

That’s great if CDI is able to do this to decouple their TCK integration testing with other specs in a way that makes sense to the main CDI specification.

 

I don’t see how that applies to Jakarta Data. It doesn’t define integration requirements with anything in Jakarta EE Platform that isn’t also in Jakarta Web Profile.

 

 

From: Scott Stark <starksm64@xxxxxxxxx>
Date: Friday, September 1, 2023 at 2:57 PM
To: jakartaee-platform developer discussions <jakartaee-platform-dev@xxxxxxxxxxx>
Cc: Nathan Rauh <nathan.rauh@xxxxxxxxxx>
Subject: [EXTERNAL] Re: [jakartaee-platform-dev] Optional parts of a Spec or a "Bridge"

I think this is the main issue that calls for a separate integration spec and TCK artifact to decouple the main spec, API and TCK from downstream specification. This is exactly what we are having to do in the CDI project where the current integration

ZjQcmQRYFpfptBannerStart

This Message Is From an Untrusted Sender

You have not previously corresponded with this sender.

    Report Suspicious    ‌

ZjQcmQRYFpfptBannerEnd

I think this is the main issue that calls for a separate integration spec and TCK artifact to decouple the main spec, API and TCK from downstream specification. This is exactly what we are having to do in the CDI project where the current integration chapters are being broken out into a separate integration specification with the subset of TCK tests that were targeting the Web Profile and Platform making up the integration spec TCK.

 

On Fri, Sep 1, 2023 at 1:52 PM Nathan Rauh via jakartaee-platform-dev <jakartaee-platform-dev@xxxxxxxxxxx> wrote:

...

 

Kyle has done excellent work with the TCK and it does not require the Jakarta Data provider to be backed by Jakarta Persistence, although some extra tests to validate Jakarta Persistence-related requirements will run if it is.  The TCK even has a mode for running in core profile (where there is no Jakarta Persistence) although Jakarta EE 11 is not targeting core profile for Jakarta Data.

 

 

From: jakartaee-platform-dev <jakartaee-platform-dev-bounces@xxxxxxxxxxx> on behalf of Scott Stark via jakartaee-platform-dev <jakartaee-platform-dev@xxxxxxxxxxx>
Date: Friday, September 1, 2023 at 2:10 PM
To: jakartaee-platform developer discussions <jakartaee-platform-dev@xxxxxxxxxxx>
Cc: Scott Stark <starksm64@xxxxxxxxx>
Subject: [EXTERNAL] Re: [jakartaee-platform-dev] Optional parts of a Spec or a "Bridge"

To ensure the cleanest separation of dependencies at both the API and TCK level this can be done in a separate bridge spec with separate artifacts, but this should be produced by the Jakarta Data project with collaboration with Jakarta Persistence

ZjQcmQRYFpfptBannerStart

This Message Is From an External Sender

This message came from outside your organization.

    Report Suspicious    ‌

ZjQcmQRYFpfptBannerEnd

 

To ensure the cleanest separation of dependencies at both the API and TCK level this can be done in a separate bridge spec with separate artifacts, but this should be produced by the Jakarta Data project with collaboration with Jakarta Persistence project members. This should be done concurrently with the Jakarta Data 1.0 spec. 

 

 

 

 

On Fri, Sep 1, 2023 at 9:33 AM Steve Millidge (Payara) via jakartaee-platform-dev <jakartaee-platform-dev@xxxxxxxxxxx> wrote:

Hi,

 

There’s a bunch of questions wrapped up in this.

 

First – Arjan’s point should Jakarta EE specifications be specifications that target the overall platform and therefore be internally consistent with the whole platform. I support this point. I think being overly abstract to support implementations outside of the overall Jakarta EE ecosystem is detrimental to Jakarta EE as a whole. This is an important future direction point. Are we writing specifications as standards for the whole Java industry or are we writing specifications that support creating multiple independent implementations within the Jakarta EE ecosystem? However I don’t want to hijack the thread for that debate.

 

Second – relating to the specific issue referenced by Werner – I support a lot of what Gavin is saying in the issue – the semantics of the API and how it works should be self contained in the specification document so that an independent implementation of the specification can be created without referring to other documents or implementations. This is especially important in Jakarta EE where we do not have a “reference implementation” you can look at and compare with.

 

Third – I support Werner’s point on Jakarta Data that it should support repositories that are not JPA. My understanding of the points made in the issue is that if that is the case then references to JPA should be removed from the top level specification document. Therefore given the current definition of optional a separate bridge specification seems logical to me, perhaps developed by the same specification project team and also included in both Web Profile and Platform. The reason I feel it needs to be a bridge spec is that it should be specified so that there can be multiple independent implementations of the bridge and these should work the same way to enable application portability between Jakarta EE implementations.

 

Thanks

 

Steve

 

 

From: jakartaee-platform-dev <jakartaee-platform-dev-bounces@xxxxxxxxxxx> On Behalf Of Arjan Tijms via jakartaee-platform-dev
Sent: Friday, September 1, 2023 2:11 PM
To: jakartaee-platform developer discussions <jakartaee-platform-dev@xxxxxxxxxxx>
Cc: Arjan Tijms <arjan.tijms@xxxxxxxxxxx>
Subject: Re: [jakartaee-platform-dev] Optional parts of a Spec or a "Bridge"

 

Hi,

 

I want to warn, again, about designing anything overly abstract. It always sounds so good and nice to be agnostic of everything, so that this proverbial guy deep in the jungle of japan can use our Java spec with Python and some Python based framework even.

 

But in practice this causes a lot of hurt, and makes things quite difficult to use.

 

Jakarta Security is, IMHO, infinitely easier to use since it just targets Servlet and CDI. Jakarta Authentication is according to many (it seems) horrible to use, precisely because it's agnostic to everything. It was designed to work with every possible representation of a request for instance, but in practice it has only ever been used with HttpServletRequest (okay, and SOAP, but it made little sense there).

 

We may want to compare this with the most popular framework out there; Spring. Does Spring ever try to be agnostic of itself, or does every Spring API depend on Spring Beans and whatever else it needs from Spring, without any shame?

 

Kind regards,

Arjan Tijms

 

 

 

 

On Fri, 1 Sept 2023 at 13:13, Werner Keil via jakartaee-platform-dev <jakartaee-platform-dev@xxxxxxxxxxx> wrote:

Hello,

After Jakarta Data was just successfully accepted to the Full and Web Profile, it is equally important for users of the Core Profile who want to use repositories and other features with the database of their choice, either NoSQL or SQL/JDBC/JPA based.

However, there is desire by some in the Persistence camp, to force Jakarta Persistence as a mandatory dependency onto Jakarta Data, see

https://github.com/jakartaee/data/pull/235

Or

https://github.com/jakartaee/data/issues/229

Which is where I also made this remark:

There are 3 options where these "implementations" or specializations could happen:

* In actual implementation modules, much like spring-data-jpa or micronaut-data-jpa do now

* In Jakarta Persistence as a downstream spec

* In a "Bridge" spec between Data and Persistence, a bit like the Portlet Faces Bridges defined by the JCP or the bridging efforts between Jakarta Security and Microprofile

A 4th option is currently not realistic, it would require optional sub-modules that depend on Jakarta Persistence/JPA etc. but Jakarta EE right now only knows "optional" for features to be phased out soon.

Although the Core Profile under 2.2. Optional Components already defined some specs that are optional for that profile, so the question is, would it be possible to do this on a detail spec level, or does such a spec need a "bridge" or another separate spec like "jakarta-data-persistence"?

Frameworks like Spring Data or Micronaut Data use JPA only in sub-modules that are more an implementation than spec/API, but of course they are no specs to begin with, so it is easier for them.

I believe, the adoption of Jakarta Data will suffer if JPA is forced down the throat of every Jakarta Data use case, whether it's NoSQL or other non-relational usage of the spec.

And let's not forget those who complained here 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