Instead of using <classpathDependencyExcludes/> in Surefire (may affect the ITs), there is a better trick. See the POM surefire-junit47. You will see the section of compiler endorsed classpath but Surefire has different one:
<plugin> <artifactId>maven-dependency-plugin</artifactId> <executions> <execution> <id>main</id> <phase>process-sources</phase> <goals> <goal>copy</goal> </goals> <configuration> <outputDirectory>${project.build.directory}/endorsed</outputDirectory> <overWriteIfNewer>false</overWriteIfNewer> <silent>true</silent> <artifactItems> <artifactItem> <groupId>junit</groupId> <artifactId>junit</artifactId> <version>4.7</version> <type>jar</type> </artifactItem> </artifactItems> </configuration> </execution> <execution> <id>test</id> <phase>process-sources</phase> <goals> <goal>copy</goal> </goals> <configuration> <outputDirectory>${project.build.directory}/endorsed-test</outputDirectory> <overWriteIfNewer>false</overWriteIfNewer> <silent>true</silent> <artifactItems> <artifactItem> <groupId>junit</groupId> <artifactId>junit</artifactId> <version>4.12</version> <type>jar</type> </artifactItem> </artifactItems> </configuration> </execution> </executions> </plugin> <plugin> <artifactId>maven-compiler-plugin</artifactId> <configuration> <compilerArguments> <endorseddirs>${project.build.directory}/endorsed</endorseddirs> </compilerArguments> <testCompilerArguments> <endorseddirs>${project.build.directory}/endorsed-test</endorseddirs> </testCompilerArguments> </configuration> </plugin> On Tue, Oct 4, 2016 at 7:47 PM, Benedikt Ritter <brit...@apache.org> wrote: > Hello Tibor, > > Tibor Digana <tibor.dig...@googlemail.com> schrieb am Di., 4. Okt. 2016 um > 02:29 Uhr: > > > Can you simplify and speed up writing integration tests in the way that > you > > would parameterize the existing JUnit 4 testing by adding Maven profiles > > (one default profile and junit5 profile) having another dependencies and > > @RunWith(Parameterized.class)? > > This would be cool because we can have identical assertion statements, > > means behavior, for multiple providers. > > > > I was already thinking about this, because right now I'm duplicating a lot > of the code from the ITs. This is definitely a good idea. But right know I > don't have a clear view of how we could implement that. Do we just share > the test class and work with separate test projects? Or do we want to even > share the test projects and work with profiles in the test project pom? > > JUnit 5 also has support for running legacy tests (they call it "vintage"). > To make a complete IT suite, we would have to run all the JUnit 4 tests > against the JUnit 5 vintage engine as well. > > Lot a work ahead :-) > > Regards, > Benedikt > > > > > > On Mon, Oct 3, 2016 at 7:38 PM, Benedikt Ritter <brit...@apache.org> > > wrote: > > > > > Hi, > > > > > > now that we have a separate branch for the JUnit 5 support in the > > surefire > > > repo, I'm asking myself how to much things forward. I've added some > > > additional IT implementations in my GitHub fork, but they all fail > > because > > > the 5.0.0-M2 release of junit-surefire-provider does not implement the > > > desired features. > > > > > > At this point I'm pretty much blocked: I can not pick up the latest > > changes > > > to the JUnit 5 provider, because the JUnit team has not released it. > The > > > JUnit team does not push the development of the provider further, since > > > they don't have integration tests... > > > Right now I think it would be best to start implementing a JUnit 5 > > provider > > > ourself in the junit5 branch, so we can add the missing features and > have > > > it ready when JUnit 5 reaches GA. > > > > > > Thoughts? > > > > > > Benedikt > > > > > > > > > > > -- > > Cheers > > Tibor > > > -- Cheers Tibor