Do we need repos for each vendor?

[David Blevins]

Two questions, do we need a separate Github org for our JWT work?

 - https://github.com/MicroProfileJWT

Would be our third org and maybe not a pattern we want to repeat.

Second gentle note is seeing four repos with “wfswarm” in the title diminishes the neutrality I’m hoping we achieve with MicroProfile.

-- 

David Blevins

http://twitter.com/dblevins
http://www.tomitribe.com

310-633-3852

[David Blevins]

On Aug 5, 2017, at 12:15 PM, David Blevins <dble...@tomitribe.com> wrote:

Second gentle note is seeing four repos with “wfswarm” in the title diminishes the neutrality I’m hoping we achieve with MicroProfile.

With some insight into the goal we can probably find a better way.

-David

[sst...@redhat.com]

This is an organization I setup to organize all of the MP-JWT related repos I'm contributing to, so it is not meant to be a general pattern. 

[Rudy De Busscher]

Hi David,

I played around with some implementations for MP JWT, which are not based on Keycloak nor swarm.

You can find the code here https://github.com/rdebusscher/microprofile-jwt-auth-ri (fork of the original, not finished I guess, code of Scott)

Instead of keycloak, it uses nimbus-jose-jwt for handling the JWT and there is a version using plain JAX-RS, plain JASPIC and JSR-375.

So indeed, some general idea how to handle the RI's of MP JWT is probably required.

regards

Rudy

[Werner Keil]

"Vendor" is the wrong word, Scott did not create a RedHat or WildFly organization, although I was a little puzzled about its creation, too.

There are many other truly vendor-specific things especially in the Conference app:

<!-- App servers -->

contains many references to special dependencies for TomEE, Payara or Wildfly.  Although the components were contributed by individual vendors, it makes it very hard without having every single one installed to even run or demonstrate this app. Not to mention vendor-specific BOMs instead of the already available 1.0 BOM (but unfortunately the more versatile microprofile-samples app also is not there yet)

If Eclipse can support what other projects did, maybe distinct sub-projects are a way to go for most of the features. That would also allow them to maintain their own version numbers independent of an "umbrella" feature or project.

Werner

On Saturday, August 5, 2017 at 9:15:28 PM UTC+2, David Blevins wrote:

[Emily Jiang]

I think we discussed the implementations on MicroProfile specs and we decided not to identify ri. It is fine to call it an implementation but not ri. It seems the repo microfprofile-jwt-auth-ri has a dependency on swarm. Should this repo be renamed to microprofile-jwt-auth-swarm or something similar?

Emily

[sst...@redhat.com]

I have renamed it

microprofile-jwt-auth-prototype

[Emily Jiang]

Thanks Scott!

[Werner Keil]

If approved, the Configuration efforts will have to differ a bit I assume. 

While an API could probably just stay where it is, both a TCK AND RI will be necessary for that.

No idea, if a JSR could start with API 1.1 or 1.2 or had to be turned back to 1.0-SNAPSHOT before a JSR is Final (most JSRs I know that are new do start at 1.0, the package namespace has to change to something like "javax.config" or similar anyway) but there must be an RI once it is approved as a JSR.

There some implementations out there, so having independent implementations looks not so hard in this case either.

Who knows, if the standard is accepted by the community, even the likes of Dropwizard or Spring might pick it up ;-)

Werner