> The status quo we're looking at is that 100% of MicroProfile implementations will ship the Jakarta EE Core Profile. They'll both already be in the box.
The problem is, that MicroProfile and MP JWT is always one step behind and especially the Jakarta Security spec could not realistically use ist API, first and foremost due to circular dependencies to different versions of the Underlying Jakarta specs:
The 2.2 SNAPSHOT of MicroProfile JWT Auth uses an older version of Jakarta Authorization:
<version.jakarta.authorization-api>2.0.0</version.jakarta.authorization-api>
So it is not even on the same level as Jakarta Security 3.0 meaning even if the next Soteria was to use it, even with Authorization unchanged it would rely on Jakarta Authorization 2.1 while MP JWT still uses 2.0. If Authorization changes for an upcoming Soteria release that gap may further increase.
Werner
> On Nov 9, 2022, at 7:54 AM, Ondro Mihályi <mihalyi@xxxxxxxxxxx> wrote:
>
> I agree with Arjan here, the functionality of MP JWT would normally be in Jakarta Security if it wasn't delayed so much.
I think we need to be careful saying things like that or people might forget the reality that Jakarta didn't yet exist, Java EE was dead and creating MicroProfile and MP JWT were the only ways forward anyone could see.
> The same applies to some other specifications in MP, e.g. Rest client is basically an extension to Jakarta REST and all of it would be natural to have in Jakarta REST. Config was planned for Java EE 8 but didn't make it, and then it was created in MP. But for a long time it was desired in Java EE and Jakarta EE, and the fact that it's now in MP shouldn't block adding Config to Jakarta EE.
>
> I also agree with David and the CN4J document that we shouldn't duplicate the effort. But the CN4J document also states that specs can move between working groups freeley, so MP JWT can move to Jakarta if it makes sense.
>
> What I would like is that MP JWT moves to Jakarta Security and Jakarta Security creates a lite profile, which could be included in Jakarta Core Profile, and thus in MicroProfile. In the same way as CDI created a new lite profile which will replace full CDI in MicroProfile 6.0.
>
> With this approach, plain Jakarta EE would have a solution for JWT and many other authentication mechanisms, without relying on Microprofile. And yes, there are still plain Jakarta EE implementations without Microprofile or with just parital MicroProfile support. Also, keep in mind that the Jakarta Security team planned to support JWT for a long time and relying on MicroProfile is not an ideal option here in the long run.
>
> Microprofile would still include only JWT, without the remaining parts of Jakarta Security and potential dependency on Servlet.
>
> Any objections to this approach?
For a move to happen we'd need to have a discussion at the CN4J level, a proposal endorsed by at least two members (one from each group) and agreement by both Working Groups in the form of a steering committee vote.
That said, I think the best path forward would be for us all to renew our efforts in contributing to MP JWT and see how far we get.
I also think the goal of bringing Jakarta EE and MicroProfile closer together technically is happening. Jakarta EE created the Core Profile and MicroProfile subsequently is requiring all MicroProfile implementations to not only implement it, but also pass the Core Profile TCK.
The status quo we're looking at is that 100% of MicroProfile implementations will ship the Jakarta EE Core Profile. They'll both already be in the box.
-David
_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev