What do you think about creating a separate module in the same vein as test-infra? I suspect this is being done to access some of the utilities provided in these tests?

On the other hand i'm not sure how that would work, as that test module would likely require code from the core source, so it would create a circular dependency, so maybe what is done here is for the best.

On the other hand i'm not sure how that would work, as that test module would likely require code from the core source, so it would create a circular dependency, so maybe what is done here is for the best.

Unfortunately classes like RequestHandlerTestHarness indeed depend on the core classes so that would create a circular dependency. Unless we move all the unit tests to a separate module as well, but that seems overkill.

Unfortunately classes like RequestHandlerTestHarness indeed depend on the core classes so that would create a circular dependency. Unless we move all the unit tests to a separate module as well, but that seems overkill.

💯 agreed with the approach you are using in that case then.

👍, on deploying test-jar. there are some failing unit tests in travis, are those caused by this?

there are some failing unit tests in travis, are those caused by this?

No these were transient failures, I triggered a new build and it passed.

No these were transient failures, I triggered a new build and it passed.

Ah ok, i'll look into that test. I could have sworn we've had issues with this particular test in the past and made it more resilient, but perhaps there is something more we can do there.