Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

add automatic conversions to violation handling #1251

Merged
merged 2 commits into from
Mar 26, 2024

Conversation

codecholeric
Copy link
Collaborator

The extensive freedom of how to create a ConditionEvent causes problems for any client that needs more structured results (e.g. tools).
ViolationHandler provides a convenient API to obtain only those sort of violations that can be handled by a client (e.g. tackling dependencies).
However, the type of the correspondingObject attached to the ConditionEvent can take many forms.
From classes to methods, method calls, dependencies or aggregated dependencies (like module dependencies) it's hard to determine the possibilities and handle them all.
Furthermore, the type of some objects (e.g. ComponentDependency isn't even public,
so there is hardly any clean way to handle these objects.

To mitigate this a little we now support transparent conversions between compatible objects.
E.g. a component dependency can also be considered a set of class dependencies.
ViolationHandler now allows to be used including these conversions that are implemented by standard ArchUnit objects where reasonable.
This allows e.g. to obtain all module dependencies as Set<Dependency> for every violation.

default <T> Set<T> convertTo(Class<T> type) {
return getEdges().stream()
.filter(edge -> edge instanceof Convertible)
.flatMap(edge -> ((Convertible) edge).convertTo(type).stream())
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have no intuition whether it makes sense that a cycle of convertible edges can be converted to the combined conversion of those edges.

Do you have a (real life) example in mind?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, Cycle -> Set<Dependency>. I think that's fair, no? It could also be Set<Set<Dependency>>, but I don't think that's easier to handle for all practical purposes (which is usually something like "I want to visualize all dependencies that form a cycle")

@codecholeric codecholeric force-pushed the improve-extension-mechanism branch 2 times, most recently from 9a9f876 to 22ef4d3 Compare March 25, 2024 00:06
The corresponding object in a `ConditionEvent` should always be the object that caused the violation,
not the condition that checked it.
Otherwise, clients that analyse the violating objects can't correctly identify the respective culprit.

Signed-off-by: Peter Gafert <[email protected]>
The extensive freedom of how to create a `ConditionEvent` causes problems for any client that needs more structured results (e.g. tools).
`ViolationHandler` provides a convenient API to obtain only those sort of violations that can be handled by a client (e.g. tackling dependencies).
However, the type of the `correspondingObject` attached to the `ConditionEvent` can take many forms.
From classes to methods, method calls, dependencies or aggregated dependencies (like module dependencies) it's hard to determine the possibilities and handle them all.
Furthermore, the type of some objects (e.g. `ComponentDependency` isn't even public,
so there is hardly any clean way to handle these objects.

To mitigate this a little we now support transparent conversions between compatible objects.
E.g. a component dependency can also be considered a set of class dependencies.
`ViolationHandler` now allows to be used including these conversions that are implemented by standard ArchUnit objects where reasonable.
This allows e.g. to obtain all module dependencies as `Set<Dependency>` for every violation.

Signed-off-by: Peter Gafert <[email protected]>
@codecholeric codecholeric merged commit b7d9dd5 into main Mar 26, 2024
21 checks passed
@codecholeric codecholeric deleted the improve-extension-mechanism branch March 26, 2024 10:09
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants