I created this artifact because we agreed we want to have the Maven build process.

I would like to deploy this project to Maven central Snapshot repositories under version 4.11.1-SNAPSHOT, and notify the JUnit community to test. For the first looking the build outcome is useful.

IMHO the release plan could be like this: 4.11-SNAPSHOT for #332 4.11.1-SNAPSHOT for this pull request 4.11.2-SNAPSHOT for OSGi + Maven pull request

What you think?

I obviously do not have server credentials user/psswd to deploy to Maven central.

Categories in suite should be multiple in annotations Categories.IncludeCategory and Categories.ExcludeCategory, and configurable by system properties as well. This pull request referst to discussions in #142 and my old pull request #354 closed by my mistake #461.

I sometimes use junit assertions even in production code to make sure no invalid data slips through. As some of my applications run under osgi it would be very handy if junit already was a valid osgi bundle.

As far as I can tell it would only be necessary to switch the to packaging in the pom to bundle and add the maven bundle pllugin. I can provide a patch if that helps.

Christian

Test that are run with the Parameterized suite currently default to a specific runner. This change adds a @ParameterizedRunWith annotation that allows a user to specify which runner the suite should use for each Test case so the user can over-ride specific functionality within the runner.

• Matchers in JUnitMatchers that are now provided by hamcrest-core are deprecated.
• The static methods now delegate to CoreMatchers
• The four Matcher classes copied from Hamcrest have been deleted.
• Using CoreMatchers where possible

Important: In some but not all cases, this change will cause compile errors for people using JUnitMatchers.hasItem(s), both(), and either().

Merging this pull request would fix #36.

Currently SuiteTest.suiteShouldBeOKwithNonDefaultConstructor() fails but I don't know what ought to be done about that. Under what circumstances does it make sense to have a Suite with no SuiteClasses? Suggestions?

I'll also be refactoring out the command line processing as per @kcooney and will writing more tests for the code that has changed.

New class: ExceptionWithThread.java (subclass of Exception that keeps information about some other relevant thread). Changed: FailOnTimeout.java (starts test in a new ThreadGroup; on timeout, looks at running threads in ThreadGroup to see which one it thinks got stuck, creates an ExceptionWithThread if it finds one); Failure.java (displays stack for the "relevant thread" if it handles an ExceptionWithThread)

The old RunNotifier uses synchronized ArrayList in Listeners.

Without the synchronization the concurrently modified Listeners throw ConcurrentModificationException on iterator.

This synchronization is no longer needed with ConcurrentLinkedQueue because it is already thread safe and non-blocking.

This change will speed up tests because of not having any locks.

Right now the test names are named sequentially 0,1, etc in Parameterized:

@Override protected String getName() { return String.format("[%s]", fParameterSetNumber); }

@Override protected String testName(final Method method) { return String.format("%s[%s]", method.getName(), fParameterSetNumber); }

It would help if the data themselves were to be used in determining the name. Proposed alternatives for name (which has to be determinited statically before Test is instantiated):

• call toString on first parameter
• call the a newly added names attribute to Parameters annotation (with default empty names for compatibility) public String[] names() default {};
• call a public, static (!) method annotated by newly-defined @TestName and accepting the same arguments as the constructor

I can provide (again) a patch. This issue was tracked as http://sourceforge.net/tracker/?func=detail&atid=365278&aid=1742040&group_id=15278 and https://sourceforge.net/tracker/?func=detail&atid=365278&aid=1630834&group_id=15278 I can submit a patch if needed

The ParallelComputer with unlimited Thread pool size is not enugh.

Thus I added methods with parameters where the user can change the Thread pool as he likes.

Opened discussion #518 and got the consensus to update ParallelComputer.

methods(ExecutorService) classes(ExecutorService) classesAndMethodsUnbounded() classesAndMethodsBounded(int nThreads) classesAndMethods(ThreadPoolExecutor) classesAndMethods(ThreadPoolExecutor pool, int minConcurrentMethods) classesAndMethods(ExecutorService poolClasses, ExecutorService poolMethods)

I see versions 4.6 and 4.7 of the bundled-libraries version of JUnit in the Maven Central repo, but no junit-dep. Can this be added by whoever is doing the uploads?

This PR adds explicit permissions section to workflows. This is a security best practice because by default workflows run with extended set of permissions (except from on: pull_request from external forks). By specifying any permission explicitly all others are set to none. By using the principle of least privilege the damage a compromised workflow can do (because of an injection or compromised third party tool or action) is restricted. It is recommended to have most strict permissions on the top level and grant write permissions on job level case by case.

I had to implement a custom equal function but I cannot report the failure with the existing functionality of Assert class. I wanted to reuse the function Assert.failNotEquals but it's private, not sure why. Can you make it public?

If subclassing the Suite class one can implement a constructor which can invoke a custom static method to specify test suite classes. This is currently not possible with subclasses ob Categories.

Therefore i propose this small fix to expose the constructor with the signature Categories(RunnerBuilder, Class, Class[]) to subclasses.

My understanding is that https://github.com/junit-team/junit4/commit/c75dcc28810aeb1c918ee7430981b31f41742ea7#diff-f35409420f2540415a9878beaf5a537248f301b6c683bb87a11016be3c9dc8b8R55 caused JUnit to begin processing @Rule fields in a defined order. The @Rule Javadoc, however, still states that the order is defined by the JVM's reflection API.

It would be good to know whether the intent is to commit to this order or not. I suppose that the current doc is technically wrong either way, since the current order is not dependent on the JVM reflection API :) But mainly I want to know how safe this is to rely on. Thanks.

(Sorry if I missed some past discussion in my searching or if I've misunderstood something.)