Hi, For the ones who haven’t seen it yet; OpenLiberty started with their own implementation of JSR 375. See:

Yes, nobody should bother creating another Java EE Security API organization on GitHub again ;-) Some JSRs have already been contributed, a few others are pending, but already mentioned. Mostly those

Now that several existing JSRs like 374 started with proposals to EE4J, I wonder what keeps this JSR from doing the same? Obvious bugs or smaller improvements without introducing whole new API

We should definitely wait for Will/Oracle input beforr creating a new branch for thid on the official repo. But if they are ok with that, I prefer it over the external organization.

I think a 'fork' to a new organization is safer. It indicates better that is an initiative of some of the EG members and associate members (or anyone else who wants to drive this forward)

p.s. I checked the githib/javaee repos, and the branches still seem to be open to be created. So for the mentioned experimental next API, shall I create two branches in

Indeed, so wondering what the best place for such shared experimenting could be. Maybe a branch such as Guillermo mentioned, or now that I think of it, a fork (as-in, a GitHub fork) for doing

If possible, an MR is the best option. But we can already start experimenting with additional + proposed features outside JCP and EE4J (I don't think Microprofile is a good place for it), and even

Just thinking out loud... Perhaps Will could open for us an API branch and non official snapshots of development work could be used by servers? Work would be done when the time for an MR arrives (or

Obviously an MR is the best route if Oracle has the appetite. If not I suggest an RI specific extension. The last resort could be a fork. Sent from my iPhone

Hi, Without an EG being active and with the EE transfer in progress so that there's being little chance of starting an EG now or before long, I wonder what the best way forward is at this moment for

This is awesome! Great to have this kind of recognition for the JSR. Disappointed I couldn't receive it in person, but I've no doubt Ivar represented us ably. -- Will Hopkins | WebLogic

Congratulations everyone and thanks Werner for letting us know!

Hi, This is super good news! The JSR also seems to be appreciated by reviewers/bloggers from IBM, jaxenter, tss, and more, so even though we maybe only got half in of what we wanted it's still very

Dear All, The JCP page has not been updated yet, but JSR 375 won the JCP Award for Most Significant JSR as announced at the JCP Party last

The other thing you can do is build with "mvn -P release". That's how the 1.0 implementation jar was built with a dependency on the 1.0 final API jar. Maven doesn't make it easy to

Hi, This issue (and workaround) is now logged as 193: https://github.com/javaee/security-soteria/issues/193 Regards, Ashley Richardson

Hi, Specifying the API version at 1.0 does indeed fix the dependency and build problem. I'll just add a Github issue reflecting my original email to the Soteria repository so its at least documented

Hi, At a quick glance, that does't look quite good at all :O The Java EE 8 samples project uses the API 1.0 pom without any issues. Both local and on a clean travis environment it could be resolved.

Hi, Now that the 1.0 release is posted on Maven Central, can someone just check if I am following the POMs completely wrong: org.glassfish.security:javax.security.enterprise 1.0 contains the following