Updated Maven dependencies #213
Conversation
Signed-off-by: Guillermo González de Agüero <[email protected]>
|
One small issue with the PR is the update to Payara 174, which already
includes Soteria.
From the top of my head 173 is the last one that didn’t. So Payara 4 174
and 181 should only be used to test Soteria embedded in the war.
…On Saturday, May 26, 2018, Guillermo González de Agüero < ***@***.***> wrote:
It now compiles with Java 10.
@arjantijms <https://github.com/arjantijms> all individual test modules
define their artifact version and the version of the
org.glassfish.soteria.test:common dependency. It's my understanding that
the correct thing would be to reference the ${spec_impl_version} version.
Is that assumption correct? That would require to update also the other
poms.
------------------------------
You can view, comment on, or merge this pull request online at:
#213
Commit Summary
- Updated Maven dependencies
File Changes
- *M* impl/pom.xml
<https://github.com/eclipse-ee4j/soteria/pull/213/files#diff-0> (13)
- *M* pom.xml
<https://github.com/eclipse-ee4j/soteria/pull/213/files#diff-1> (20)
- *M* test/pom.xml
<https://github.com/eclipse-ee4j/soteria/pull/213/files#diff-2> (53)
Patch Links:
- https://github.com/eclipse-ee4j/soteria/pull/213.patch
- https://github.com/eclipse-ee4j/soteria/pull/213.diff
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#213>, or mute the thread
<https://github.com/notifications/unsubscribe-auth/AC5XTu4TkdBBPLnCtuJq9A4ajP126C4Sks5t2Z1_gaJpZM4UPAiu>
.
|
|
Once we move to Java EE 8 application servers only the embedded profile will make sense for all of them, no? I might be missing something, but as far as I see, the "provided" profile assumes the application server contains the current snapshot Soteria version, which will rarely be the case. If that's the case, we could even add Payara 5 and a Liberty server with Java EE 8, testing all of them with the bundled profile, and remove the "provided" one. |
|
We'll have to see how we exactly go forward with it once there are EE 8 dependencies and all EE 8 servers have a EE Security implementation. One approach woud be to simple use the tests as a TCK-lite, so just testing a given server works correctly and not necessarily testing the Soteria snapshot. At that point we might be better off moving the tests to EE 8 samples and rubber stamp that as the (additional) TCK. Another approach would be to update a server in a separate step with the current Soteria snapshot. This would only make sense for those servers using Soteria. Effectively this is what the Mojarra tests do. |
|
A bit +10 on that. I am about to offer a PR for #214 and it took 25 minutes to build all of Soteria !!! :-O |
|
;) |
|
Thanks good point. In this case I did of course want to be sure, all tests pass even after the version number changed;-) |
|
I can imagine ;) With port randomisation the tests can speed up quite a bit by running them in parallel (using the -TC1 option for example). Payara Micro supports this, but it would need a target for updating it with the newly build jar. |
|
I changed the reviewer from the available list to @ivargrimstad but the merge would have to be manual because other PRs changed the POMs. |
Signed-off-by: Guillermo González de Agüero <[email protected]>
I still see value in testing latest Soteria on different servers even when they don't use it themselves. For example, when we get your JACC+CDI idea working, it would be great to be able to use it on any server without waiting for everyone to implement the spec. In the particular case of Security, which has always been one of the nightmares of Java EE, it's very to compelling from a user point of view to see that I can just plug a JAR on my application and it just works. It could be a way to make vendors take JACC more seriously. |
|
@arjantijms back again to this particular PR, I went the easy way and reverted server versions to their original values. We'll be able to revisit it once we get CI working again |
It now compiles with Java 10.
@arjantijms all individual test modules define their artifact version and the version of the
org.glassfish.soteria.test:commondependency. It's my understanding that the correct thing would be to reference the${spec_impl_version}version. Is that assumption correct? That would require to update also the other poms.