Avoid implementation-specific filters in recheck

[beatngu13]

We currently have implementation-specific filters (e.g. for recheck-web) in recheck (under src/main/resources/filter/), which is not optimal. Implementations should provide their own filters, so that recheck isn't bloated with filter files over time. Moreover, adapted filters shouldn't require PRs and releases in/of recheck, but of the corresponding implementation.

@roesslerj @diba1013 I know you had this discussion before and it wasn't straightforward to implement. Could you provide a quick summary, such that we can discuss possible alternative solutions?

[roesslerj]

Quick summary: Filtering happens mainly in the GUI and the CLI. So far, these are independent of web, xml, json etc. If we move filters to the respective projects, we create a dependency from GUI/CLI to that project. Although I very welcome the general idea, I currently have no idea how to resolve that conflict of interest.

[beatngu13]

Two possible solutions come to my mind:

1. A specific implementation installs its filters in a common directory (we already thought about something like ~/.retest/, where we could use a filter/ or filters/ subfolder). The user could also do this manually to re-use filters globally, across multiple projects.

2. A specific implementation appends its filters to the test report. For instance, our TestReport class already has a field ignoredAttributes that contains the attributes ignored during the test. We could introduce another field which provides the possible filters that the frontend can re-use.

[roesslerj]

I think

1. would be a good idea ... but needs to be implemented and introduces complexity regarding management and updates. Therefore I would postpone that until later.
2. ignoredAttributes is meant for other attributes that don't even make it into the report. That doesn't work on multiple levels...

[beatngu13]

1. would be a good idea ... but needs to be implemented and introduces complexity regarding management and updates. Therefore I would postpone that until later.

Sure, needs work and we have to go through the different use cases. But it may work.

2. ignoredAttributes is meant for other attributes that don't even make it into the report. That doesn't work on multiple levels...

I didn't mean to re-use ignoredAttributes. Consider this:

• RecheckImpl (i.e. recheck) asks the adapter (e.g. recheck-web) for its filters, for instance, via a method RecheckAdapter#getFilters() that does something like SearchFilterFiles.
• recheck then embedds this mapping from filter names to actual filters in the test report(s) it creates, e.g., via a field possibleFilters.
• Afterwards, the frontend (review, recheck.cli, …) can use the embedded filters and provide them to the user without depending on any specific implementation.

[roesslerj]

Idea for a possible solution: We wanted to implement a referencing mechanism in filters / ignore anyway. Something like: import URL

If we do that, we can implement it to be a general URL. Then we can put the filters on the web, or even reference them from within a release jar/zip. Let's talk about that in detail in person...