feat(Event Frame Work): add intermediate superclass for PolicyDefinition Events hierarchy

[janpmeyer]

What this PR changes/adds

Add a 'intermediate' superclass for the Event Payload Classes of the PolicyDefinition classes.

Why it does that

Improve the work with the Event Framework and give the possibility to filter Events on a bigger group of events.

Linked Issue(s)

Closes #1914

Checklist

• added appropriate tests?
• performed checkstyle check locally?
• added/updated copyright headers?
• documented public classes/methods?
• added/updated relevant documentation?
• assigned appropriate label? (exclude from changelog with label no-changelog)
• formatted title correctly? (take a look at the CONTRIBUTING and styleguide for details)

[codecov-commenter]

Codecov Report

Merging #1915 (782d100) into main (8737a4f) will not change coverage.
The diff coverage is 100.00%.

@@           Coverage Diff           @@
##             main    #1915   +/-   ##
=======================================
  Coverage   62.78%   62.78%           
=======================================
  Files         781      782    +1     
  Lines       16614    16614           
  Branches     1079     1079           
=======================================
  Hits        10431    10431           
  Misses       5732     5732           
  Partials      451      451           

Impacted Files	Coverage Δ
...vent/policydefinition/PolicyDefinitionCreated.java	100.00% <100.00%> (ø)
...vent/policydefinition/PolicyDefinitionDeleted.java	100.00% <100.00%> (ø)
...policydefinition/PolicyDefinitionEventPayload.java	100.00% <100.00%> (ø)

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

[jimmarino]

Please include documentation

[jimmarino]

How about: "Contains data related to policy definition events"?

[janpmeyer]

I add this additionally to the current information, ok?

[jimmarino]

Please include documentation

[jimmarino]

Please add documentation

[janpmeyer]

@jimmarino Added the asked documentation. Just give me a feedback if its the way you want it.
If it is ok, i will add it the same way to the other PRs.

[jimmarino]

I don't think this is necessarily related to this PR, but the PR highlights an issue: the event class hierarchy seems more complicated than it needs to be. Specifically, there are payload classes, some of which are package level, and others which are inner classes. This contributed to some confusing class hierarchies and a lot of extra classes.

@ndr-brt Why can't we flatten the event class structure by keeping payloads in the event? Common fields can be placed on abstract classes and with concrete classes containing the payload data directly. We don't need the ability to partially unwrap events, so wouldn't this make things easier and more concise?

We can also move this to a discussion instead of polluting the PR.

[ndr-brt]

I don't think this is necessarily related to this PR, but the PR highlights an issue: the event class hierarchy seems more complicated than it needs to be. Specifically, there are payload classes, some of which are package level, and others which are inner classes. This contributed to some confusing class hierarchies and a lot of extra classes.

@ndr-brt Why can't we flatten the event class structure by keeping payloads in the event? Common fields can be placed on abstract classes and with concrete classes containing the payload data directly. We don't need the ability to partially unwrap events, so wouldn't this make things easier and more concise?

We can also move this to a discussion instead of polluting the PR.

@jimmarino the decision to have the payload separated from the Event class was taken down the road, I remember some discussion with @paullatzelsperger about this and keeping them separated seemed like the best option, the main goal that it achieves is to keep the event data (that's related to the context, it can be called "metadata" or "headers") separated from the payload data (that's strictly related to the event) also on a serialization level.
One positive aspect of this separation appears on the cloud-events extensions, where the event data is used to actually fill the cloud event metadata, and the payload alone is the "cloud event data":
https://github.com/eclipse-dataspaceconnector/DataSpaceConnector/blob/76a38259cd25bff93984c17d2afa28fa3fa94d52/extensions/common/events/cloudevents-http/src/main/java/org/eclipse/dataspaceconnector/events/cloudevents/http/CloudEventsPublisher.java#L65-L75

[janpmeyer]

So im going to adjust the documentation as you described @jimmarino and push it to the PRs.

For the structure you are gonna open a discussion. Are you fine with this @jimmarino and @ndr-brt ?

[ndr-brt]

So im going to adjust the documentation as you described @jimmarino and push it to the PRs.

For the structure you are gonna open a discussion. Are you fine with this @jimmarino and @ndr-brt ?

Yes I'm fine with it, I would go and merge these "superclass" PRs, then discuss modeling in parallel.