add automatic conversions to violation handling #1251
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
hankem
approved these changes
Mar 4, 2024
archunit/src/test/java/com/tngtech/archunit/testutil/assertion/ArchRuleCheckAssertion.java
Outdated
Show resolved
Hide resolved
archunit/src/main/java/com/tngtech/archunit/lang/EvaluationResult.java
Outdated
Show resolved
Hide resolved
archunit/src/test/java/com/tngtech/archunit/core/domain/JavaAccessTest.java
Outdated
Show resolved
Hide resolved
| default <T> Set<T> convertTo(Class<T> type) { | ||
| return getEdges().stream() | ||
| .filter(edge -> edge instanceof Convertible) | ||
| .flatMap(edge -> ((Convertible) edge).convertTo(type).stream()) |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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
force-pushed
the
improve-extension-mechanism
branch
2 times, most recently
from
9a9f876
to
22ef4d3
Compare
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
force-pushed
the
improve-extension-mechanism
branch
from
22ef4d3
to
771df06
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The extensive freedom of how to create a
ConditionEventcauses problems for any client that needs more structured results (e.g. tools).ViolationHandlerprovides 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
correspondingObjectattached to theConditionEventcan 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.
ComponentDependencyisn'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.
ViolationHandlernow 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.