User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.1.0
On 10/14/21 4:35 PM, Jean-Louis
Monteiro wrote:
You are probably right Scott.
I was mentioning as an example of solutions I see nowadays.
But it probably does not apply to what we need.
Maybe not today but testcontainers does look interesting.
That being said, I believe the difficult part in the TCK
and where we should spend time isn't necessarily on booting up
or shutting down the container we are testing against.
The TCK provides 1 or 2 interfaces for that and it's pretty
trivial to implement for newcomers and for existing servers,
pretty much everybody has implemented it already.
IMO, the difficult part is in the size of the TCK (over 2 million
lines of test code). Newcomers or even existing contributors don't
really understand enough of the TCK internals, I'm learning a lot
but there is more to learn every day. Instead of teaching the
internals, I think the current idea is to reduce the TCK complexity
in different ways so that future generations can have an easier time
maintaining the TCK. This will come in waves and we are all welcome
to make mistakes along the way. The important thing is that we work
together and make corrections as needed.
Splitting down the TCK so we can compose new profiles, to
make them easier to run and debug or even to move them to
their respective specifications.
This is probably what I'd be focusing on.
Good points.
IMO, most of the effort of splitting the TCK is currently
occurring on individual component specification but we also want
to reduce complexity for those component specifications that
remain in the Platform TCK, such that those component
specifications could easily just fork their tests from the
refactored Platform TCK. Even if those component specifications
remaining in the Platform TCK do not fork their tests, we still
benefit from having an easier to maintain Platform TCK.
Thanks! It looks like they have Podman support as well
which is great!
That also looks like a decent option as well, although
from my quick look, testcontainers sounds like a general
solution for wrapping Docker (or Podman) but not deploying
Jakarta EE test archives. Obviously, all of the testcontainers
users are not prevented from doing their testing
with whatever technologies that they are using.
Thanks for sharing!
Scott
We use it in Eclipse Jetty to test HttpSession
storagte integrations with things like Infinispan,
MongoDB, Hazelcast, Memcache, MySql.
- Joakim
On Thu, Oct 14, 2021
at 12:43 PM Scott Marlow <smarlow@xxxxxxxxxx>
wrote:
On 10/5/21 4:03 AM, Jean-Louis Monteiro
wrote:
That is a good point Olivier.
I'm myself a bit worried about setting a
hard dependency to Arquillian in the TCK
I have overall the same feeling and I see
a lot of people moving away from Arquillian
to testcontainers.
Could you please share a link for
"testcontainers"?
Thanks,
Scott
Wondering if we are doing a long term
choice with Arquillian.
On Tue, Oct
5, 2021 at 9:54 AM Olivier Lamy <olamy@xxxxxxxxxxx>
wrote:
Hi,
We discussed using arquillian which sounds
like a good idea.
I started looking at Jetty support but I
have a bit of concern on the project.
last commit 31/03/2017 [1]
and tomcat support is not better [2]
I guess we have some contacts here @ redhat
to ask if
maintenance/upgrade is scheduled?
As Jetty committer I'm happy to do the job
on jetty support.