@kcooney , I just browsed through `Categories.CategoryFilter` and think it's way too complicated for what it needs to do -- it breaks the SRP. For example, there's no need to implement both categories include and exclude filtering in the same class. Rather, have one filter implement categories inclusion, another one implement categories exclusion, then use `Filter.intersect()` to combine both. Such a design makes it more amenable to combining other filters, too (eg an `IgnoreFilter` can be created that would obsolete specific `@Ignore` processing in JUnit (IIRC, such processing violates DRY since it occurs in at least two different places).

IMO (and I can surely be biased towards my own implementation :-), `Categories.CategoryFilter` ought to be deprecated in favor of `CategoriesIncludeFilter` and `CategoriesExcludeFilter`. I'm not opposed to making the latter two inner classes of `Categories`.

I'm already working on a 'FilterFactory' in order to support the --filter option (and possibly XML-based configurations if it's decided to move in that direction in the future). Such a factory was actually needed for our Ant task (especially since we do allow custom-filters to be used). (FWIW, I'd like to move as much of this functionality into JUnit proper since we're moving towards using Gradle for our builds and it looks like it's easier to (finally) contribute to JUnit rather than reimplementing something hacky in Gradle).