Closed abelsromero closed 1 year ago
Good idea! I also think that it would be good to "slim" down our dependencies. Although I hate to say it I would be fine with dropping Arquillian.
The only reason should be the amount of work :) But if we can migrate gradually then I think the task would be far less intimidating.
Although I hate to say it I would be fine with dropping Arquillian.
Me too, it's not only part of the project but of the contributors. But in the end, even if we could keep it using the RC versions, using a JUnit extension means fewer dependencies and a framework more supported. And it's easier for contributors too. I see really no advantages in Arquillian. So far I have been able to remove Arquillian from some tests adding a few lines to init Asciidoctor and the classpath tools. That's the part we can refactor to reduce boilerplate, but it's not a big complexity.
But if we can migrate gradually then I think the task would be far less intimidating.
The current PR aims for that, but there's the issue of Spock compatibility, newer versions have removed org.spockframework.runtime.Sputnik
which org.jboss.arquillian.spock.ArquillianSputnik
uses, so I've been forced to remove Arquillian wherever we had @RunWith(ArquillianSputnik)
:disappointed: .
That's maybe the biggest re-write so far.
PS: btw, org.junit-pioneer:junit-pioneer
does not pull any third-party lib which is nice.
Trying to bump JUnit to v4 to JUnimake use of newer features I am finding road-blockers.
Normal JUnit4 and some Spock tests can make use of the vintage compatibility library, but those with Spock and Arquillian can't. I see Arquillians hasn't made a proper release in a long time, and the latest Spock integration (
arquillian-spock-core
) is1.0.0.CR1
from Sept 2019, and is not compatible with newer Spock versions.Is there any reason no to start rewriting tests to remove Arquillian dependency? I am thinking of re-writing the features as a JUnit5 extension that should work.
I am planning to do this in 2 PRs: