Move smallrye-jwt build API into smallrye-jwt-build repository

[Sergey Beryozkin]

Hi All

Right now the smallrye-jwt repository contains an implementation of the JWT build API [1].

While the API itself has had some good user feedback, the problems with the fact it is shipped as part of `smallrye-jwt` are as follows:

1. If the users just want to generate a JWT token and do not have MP JWT endpoints then it costs them by bringing the dependencies they don't need. I think it actually limits the reach of this API significantly

2. If the users do have MP JWT endpoints and do not plan to generate the tokens then they have the code around which they can't exclude - this is not a major problem because this generate code is quite lightweight and many libraries do have such code which is not of any interest to a given user as well :-)

Re point 1, I'd like it to be resolved for the OIDC client Quarkus branch I'm working upon to support the client_credentials JWT assertion authentications as in many case the users will not have the MP JWT servers but 'plain' Quarkus servers acting as OIDC service clients for ex.

This is why I'd like to move it into its own `smallrye-jwt-build` repository and have `smallrye-jwt` depend on `smallrye-jwt-build`: this will improve the modularization and give the users more options and should give this API more visibility.

Note I've opened an MP JWT PR to bring this JWT build API into MP JWT which I will have to refresh for MP JWT 2.0.

This implies, that once this PR is completed, MP JWT 2.0 TCK will have the JWT build tests. So smallrye-jwt by continuing depending on `smallrye-jwt-build`, will have these tests passing, while those users who don't really need to worry about TCKs can still exclude it if they prefer.

Roberto, others, does it sound reasonable ? Can a new `smallrye-jwt-build` repository if it sounds reasonable ?

Cheers, Sergey

[1] https://github.com/smallrye/smallrye-jwt/tree/master/implementation/src/main/java/io/smallrye/jwt/build

[Sergey Beryozkin]

The only catch I forgot to mention is that

https://github.com/smallrye/smallrye-jwt/tree/master/implementation/src/main/java/io/smallrye/jwt/algorithm

is shared between MP JWT endpoints config and this build API. This is what confusing me, but I thought about it again and again and decided it would not be a big deal if `smalrye-jwt` and `smallrye-jwt-build` would their own copies of these 3 enum classes, they may vary in a number of algorithms constants going forward, etc

Cheers. Sergey

[Sergey Beryozkin]

Looking more into it: there is also some intersection in the way the keys are loaded, `ResourceUtils` in particular which is used by both the builder API impl and MP JWT impl to load some type of keys, it is not a big class though.

JWT Build API also allows to re-create a JWT token given the injected JsonWebToken (ex, in scope of the MP JWT server where a new audience has to be created, etc).

So it is not a straightforward copy to a new repository, but it feels it is the right thing to do.

That said, perhaps I should take some more time to think about it; feedback will be welcome though

Cheers. Sergey

[Roberto Cortez]

Hi Sergey,

I agree with the problem statement and we should offer separate dependencies to users can pick which want to use.

I’m wondering if that needs to be done in a separate repository. Maybe it can be a separate module in the main SR JWT repo. In SR Config, we do have several submodes that users can include on top of the implementation to add additional behaviour. It may also help out to separate the code if done in the same repository while we are not sure how to do it properly. Finally, the release version is the same, which aligns all dependencies and makes it easies for the consumer to know which version to use.

What do you think?

--
You received this message because you are subscribed to the Google Groups "SmallRye" group.
To unsubscribe from this group and stop receiving emails from it, send an email to smallrye+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/smallrye/CAOtGrGLCm0EyvV5W%2BGTA-8e-7zQqekRA5UqT%2B94zcjKKH2Gbdg%40mail.gmail.com.

[Ladislav Thon]

I was going to suggest the same as Roberto -- why not split it into a separate Maven module inside SmallRye JWT? That way, you can easily factor out other shared code (such as the *Algorithm enums) into yet another module.

LT

st 18. 11. 2020 v 0:57 odesílatel 'Roberto Cortez' via SmallRye <smal...@googlegroups.com> napsal:

To view this discussion on the web visit https://groups.google.com/d/msgid/smallrye/EB479A84-FDEC-4148-BCBB-A5563E0E7532%40yahoo.com.

[Sergey Beryozkin]

Hi Roberto, Ladislav

This simple idea has never even occurred to me :-), I was about to create a new test repository in my account and start experimenting, oh dear, glad you've prevented me from doing it :-).

I know we already have several modules in smallrye-jwt, but I guess what blocked me mentally is that the main code has only one `implementation` module.

So yeah, the new module inside the same smallrye-jwt repository plan is nice, thanks

Sergey

To view this discussion on the web visit https://groups.google.com/d/msgid/smallrye/CALbocOmtAAHB7nCETyf2ML1UphA32cuVs4zf7jbDNQbPKDqE%3Dw%40mail.gmail.com.

[Ladislav Thon]

In SmallRye Fault Tolerance, we have 4 sub-modules in the `implementation` module, and an extra `api` module outside of `implementation`, and I think other SmallRye projects use that layout too.

LT

st 18. 11. 2020 v 11:54 odesílatel Sergey Beryozkin <sbery...@gmail.com> napsal:

To view this discussion on the web visit https://groups.google.com/d/msgid/smallrye/CAOtGrG%2BNVPghL7GSnQpRBLCM9rTyCWXOBp%3DhnZ3AO1j0SK90Qg%40mail.gmail.com.

[Sergey Beryozkin]

Sure, this would certainly keep the top level list compact, while I can have something like this:

- implementation

   - jwt-auth

     (because the MP JWT repo name is microprofile-*jwt-auth*) - the current 'implementation' module minus the build api

   - jwt-build - the new how for the build api

other projects (like smallrye-config) have many top-level siblings instead, but the implementation/* should probably work well for smalltye-jwt

Cheers, Sergey

thanks, Sergey

To view this discussion on the web visit https://groups.google.com/d/msgid/smallrye/CALbocOkdDzLhdP_QMH9rHBUuH%3DXBkuL39G0nLFw6k9g_D2sjRw%40mail.gmail.com.

[Sergey Beryozkin]

Sorry

> - jwt-build - the new how for the build api

I meant

- jwt-build - the new *home* for the build api

:-)