chore: Define a single junit5 version across the project; i.e. don't …

[rhusar]

…maintain a separate version for ITs

[rhusar]

@jamezp Unless this was intentional?

[jamezp]

It was intentional to keep the integration-tests standalone so to speak. See #581 (comment).

I don't have a strong opinion either way, but the intent was so we could test any version of Arquillian.

[rhusar]

It was intentional to keep the integration-tests standalone so to speak. See #581 (comment).

I don't have a strong opinion either way, but the intent was so we could test any version of Arquillian.

I see. But that's kinda of the the sole purpose why we have these -Dversion.junit5=xyz properties if you want a custom run.. :-)

[jasondlee]

+1 to Rado's solution, fwiw.

[jamezp]

It was intentional to keep the integration-tests standalone so to speak. See #581 (comment).
I don't have a strong opinion either way, but the intent was so we could test any version of Arquillian.

I see. But that's kinda of the the sole purpose why we have these -Dversion.junit5=xyz properties if you want a custom run.. :-)

Well, not quite. That controls the version of JUnit, not Arquillian. The idea is you could simply do something like:

cd integration-tests
mvn clean verify -Dversion.org.arquillian.core=1.9.1.Final

I do realize there is a bug in the POM not allowing this. It's not something we have to do, but it was an explicit ask to do so.

Again, I don't have a strong opinion on this as there are other ways to handle that.

[rhusar]

Well, not quite. That controls the version of JUnit, not Arquillian. The idea is you could simply do something like:

Well, but to control version of arquillian that's what git checkout 1.9.1.Final is for :-) Otherwise we would be assuming everything is binary compatible.