Simplify abstraction for events in regard of FailFast waiters

[istraka]

I find abstraction for getting and filtering events a bit complicated:

OpenShift class returns EventList instance which is implements List<Event> . The class provides filter method that returns EventListFilter instance that encapsulate functionality over the stream of events for filtering and collecting purpose.

This is IMHO too complicated and does not serve the purpose. What I suggest:

1. Getting rid of EventList class.
2. Do not encapsulate the filtering but rather have a class that provides predicates for filtering purposes - functionality would be the same.

Scenario:
Now:
Method foo needs certain events. It gets EventList, then EventListFilter and call some methods to filter events and then collect it.
If there is need of custom filtration it needs to be implemented in EventListFilter or foo method get the stream from EventListFilter and work on it that way.

Cons: it is not very easy to use

After:
Method foo needs certain events. It gets List<Event> from OpenShift and then work over the stream in standard way. It may use EventFilters class that provides Predicate<Event> instances (same functionality as in EventListFilter)

Pros: standard way of use stream, filters and so on. Easy to use

How to get there:

• Deprecate OpenShift#getEventList() and re-enable OpenShift#getEvents (remove deprecation) - this is kind of weird, I know
• After release implement the change, remove OpenShift#getEventList() and EventList in following release

[mnovak]

Could you provide usage examples of code for comparison, please?

[istraka]

Yeah, there is EventListFilter that encapsulate work over a stream of Events for filtration purposes. The main point is to get rid of EventList and replace EventListFilter class with EventFilters class that provides static methods to get Predicate<Event>.

Then we would have

openshift.getEvents().stream().filter(EventFilters.someFIlter("yada yada"))

instead of

openshift.getEventList().filter().ofEventTypes("type1", "type2")

IMO it is too complicated and learning curve is too big. It is not a standard pattern. It might look smoother, but you need to read lots of code to know what is going on.