Move TestClassTest to package org.junit.runners.model.

It is common to add tests to the same package as the class under test.
Create a class TestWithParameters.

This class keeps the data together that are needed for creating a runner for a single data set of a parameterized test. This makes it also clear, that the computation of the name is not the responsibility of the runner but of the Parameterized class.
Extract BlockJUnit4ClassRunnerWithParameters.

Separate the class from the Parameterized runner. Makes it clear, that it is designed for reuse.
Use a ParametersRunnerFactory for creating the test for a set of parameters.

There's now an explicit component for creating the runner of a single set of parameters. IMHO this is a better extension point than overriding a method.

The factory can be specified by the @UseParametersRunnerFactory
annotation or you can subclass the Parameterized class and provide
the factory to its constructor.
Small fixes, mainly in throws signatures
Merge pull request #867 from dbrazhnikov/signature_fix

Small fixes, mainly in throws signatures
fixes #177

null check for test class in ErrorReportingRunner
Merge pull request #871 from clumsy/#177

fixes #177
fixes #875

Fixes https://github.com/junit-team/junit/issues/875

In versions 4.7 through 4.11 setting up a Timeout @Rule with a value of
0 would result in no timeout. In 4.12 FailOnTimeout switched to using
FutureTask.get(timeout). That method treats non-positive timeouts to
mean "timeout right now".

This fix checks that the timeout value is positive before using it,
and otherwise will wait indefinitely.
Merge pull request #876 from madrob/#875

Change the Timeout rule to never timeout the test if zero is passed in. Fixes #875
Merge pull request #773 from stefanbirkner/parameterized-runner-factory

Parameterized runner factory
Verify that test classes are public.

Test classes should be public in order to avoid problems with
reflection caused by the security manager. Public classes are always
accesible.
Don't verify the visibility of a method's declaring class.

I would not expect FrameworkMethod.validatePublicVoid(...) to test
visibility of the declaring class. Since the last commit the runner
itself verifies that a test class is public. Hence we can safely remove
this validation from FrameworkMethod.

This fixes #749 (JUnit cannot be build with JDK 8), too.
Build JUnit with JDK 8 on Travis.

We can now build JUnit with JDK 8, because #749 is fixed.