Allow retrieving claims by using the Claims enum

[andreas-eberle]

I think it would be a good idea to add a method JsonWebToken.getClaim(Claims claim) to allow retrieving claims by using the Claims enum. At the moment one is forced to write unnecessarily bloated code like jwt.getClaim(Claims.groups.name()). This is even true for the default methods given in the interface JsonWebToken. Adding this method could make code more readable.

Let me know if you want a PR for this.

[sberyozkin]

@andreas-eberle +1, 1.2 is the next version so we can't get the implementers updating the existing working code, but for 2.0, yeah, why not. Though it would need to be tied with #100.
Thanks

[rdebusscher]

This is a compatible change since it just adds a method, so it can be included in 1.2

[sberyozkin]

@rdebusscher it is compatible for the users but requires the implementations to update their existing implementation code. I don't really mind to be honest from our own implementation's point of vew, but we can't just do it for the minor release ?

[rdebusscher]

It is no problem that a minor release require a change to the implementation code. In fact, that is the general rule, otherwise not much will change.

However, It can't introduce a breaking change.

So I agree that this change, small (only a couple of lines) but very helpful for the developers.

[sberyozkin]

@rdebusscher That said the focus is on the users, so well, I don't mind it be included in 1.2 then.

[sberyozkin]

Sounds good. @andreas-eberle Go ahead please with your PR :-)

[andreas-eberle]

I added the methods with default implementations forwarding to the old methods. So the code is doing exactly the same and other implementations also should not have to adapt anything.

[sberyozkin]

Very good, thanks

[sberyozkin]

@andreas-eberle @rdebusscher
Please see #156 for the reasons why it had to be reopened. The PR for this issue needs to have a baseline plugin updated too. For now I'm changing the milestone to 2.0 but will be happy to put back to 1.1

[sberyozkin]

My understanding of this plugin is that the interfaces can not be changed for a given baseline, any idea how it can be fixed ?

[sberyozkin]

MP Config has this configuration:

<configuration>
                    <base>
                        <version>1.3</version>
                    </base>
</configuration>

But I'm not sure what can we put there in our case to allow new method additions to the existing interfaces available in 1.1.1. Has someone dealt with a similar issue before ? I can do a PR myself once I know how to fix it

[andreas-eberle]

From what I see in the pom, the used bnd plugin versions seem very old (October 2017) while there exist a newer version 5.0 from January 2020. Maybe these problems are fixed in the newer versions?

[andreas-eberle]

@sberyozkin, @rdebusscher : It seems the relevant version is actually the version in the annotation here https://github.com/andreas-eberle/microprofile-jwt-auth/blob/add-get-claims-with-claims/api/src/main/java/org/eclipse/microprofile/jwt/package-info.java#L40 and not the dependency version.

The plugin wants us to increase this version from 1.0 to 1.1. It does not accept an increase from 1.0 to 1.0.1. Should I add this increase in my PR or should we try to find a way to not make this increase?

[andreas-eberle]

Btw, you can get more details on the error message when using the following as configuration for the bnd-baseline-maven-plugin.

<configuration>
      <fullReport>true</fullReport>
</configuration>

[sberyozkin]

Hi @andreas-eberle Thanks, so the next version will be 1.2 (we are on 1.2-SNAPSHOT) and the current tag is 1.1.1. In that case the package property should be 1.1.1 ? What I don't understand is why the PR build passes. I agree with @rdebusscher that we need to fix the plugin anyway for us to be able to change the existing methods in the future.
Should we remove tat osgi package property, and add a base.version 1.1.1 ?

[andreas-eberle]

Although I never really worked with osgi, I think it would make sense to have the same osgi version tag as the module version. However, you have two packages under the org.eclipse.microprofile main package with both having their own package-info.java file. This will mean you sometimes will increase the version of one of these packages without changing the classes in that package. Just so you are aware of that. I don't think this is an issue.

Will you make a PR to increase the version again, or should I send you one?

[sberyozkin]

Hi @andreas-eberle You may have seen a microprofile forum thread, @Emily-Jiang explained how this plugin operates. So indeed, lets do the following:

• increase that OSGI property to 1.1 to indicate we are doing the minor changes;
• add that full report property
• and update to the latest version

And please resubmit your PR alongside those changes; please use mvn clean install to verify.
I've said I can do a PR myself, would appreciate though if you could do it all as part of a single PR

Thanks

[andreas-eberle]

@sberyozkin: I added the changes to my branch and opened a new PR #158.