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
