|
Independent JSR 375 implementation
Hi,
For the ones who haven’t seen it yet; OpenLiberty started with their own implementation of JSR 375.
See:
Hi,
For the ones who haven’t seen it yet; OpenLiberty started with their own implementation of JSR 375.
See:
|
By
Arjan Tijms
·
#696
·
|
|
Re: Java EE Security.Next
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
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
|
By
Werner Keil
·
#695
·
|
|
Re: Java EE Security.Next
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
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
|
By
Werner Keil
·
#694
·
|
|
Re: Java EE Security.Next
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.
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.
|
By
Guillermo González de Agüero
·
#693
·
|
|
Re: Java EE Security.Next
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)
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)
|
By
Rudy De Busscher
·
#692
·
|
|
Re: Java EE Security.Next
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
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
|
By
Arjan Tijms
·
#691
·
|
|
Re: Java EE Security.Next
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
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
|
By
Arjan Tijms
·
#690
·
|
|
Re: Java EE Security.Next
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
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
|
By
Rudy De Busscher
·
#689
·
|
|
Re: Java EE Security.Next
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
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
|
By
Guillermo González de Agüero
·
#688
·
|
|
Re: Java EE Security.Next
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
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
|
By
reza_rahman <reza_rahman@...>
·
#687
·
|
|
Java EE Security.Next
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
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
|
By
Arjan Tijms
·
#686
·
|
|
Re: JCP Award 2017
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
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
|
By
Will Hopkins
·
#685
·
|
|
Re: JCP Award 2017
Congratulations everyone and thanks Werner for letting us know!
Congratulations everyone and thanks Werner for letting us know!
|
By
Guillermo González de Agüero
·
#684
·
|
|
Re: JCP Award 2017
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
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
|
By
Arjan Tijms
·
#683
·
|
|
JCP Award 2017
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
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
|
By
Werner Keil
·
#682
·
|
|
Re: Release 1.0 in Maven Central and its dependency tree
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
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
|
By
Will Hopkins
·
#681
·
|
|
Re: Release 1.0 in Maven Central and its dependency tree
Hi,
This issue (and workaround) is now logged as 193: https://github.com/javaee/security-soteria/issues/193
Regards,
Ashley Richardson
Hi,
This issue (and workaround) is now logged as 193: https://github.com/javaee/security-soteria/issues/193
Regards,
Ashley Richardson
|
By
Ashley Richardson
·
#680
·
|
|
Re: Release 1.0 in Maven Central and its dependency tree
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,
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
|
By
Ashley Richardson
·
#679
·
|
|
Re: Release 1.0 in Maven Central and its dependency tree
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,
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.
|
By
Arjan Tijms
·
#678
·
|
|
Release 1.0 in Maven Central and its dependency tree
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
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
|
By
Ashley Richardson
·
#677
·
|