Add API to create ArchConditions from predicates #904
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
u3r
approved these changes
Jul 8, 2022
There was a problem hiding this comment.
All in all it looks good to me - just two remarks for my curiosity.
"Fixed it up a little" puts a different meaning to "a little" than I would though ;-)
Thanks for doing this - as announced I didn't find any time the passt few weeks for following up on this.
archunit/src/main/java/com/tngtech/archunit/lang/conditions/ArchConditions.java
Show resolved
Hide resolved
|
Okay, let's say |
|
All good for me, looking forward to getting rid of some copy/pasta in our codebase with the new version! |
There have been some leftovers from the Java 8 migration like obsolete explicit type arguments where it can be inferred. Signed-off-by: Peter Gafert <peter.gafert@tngtech.com>
Signed-off-by: Peter Gafert <peter.gafert@tngtech.com>
The naming was a little inconsistent, `IsConditionByPredicate` took the details description as model for the name ("is/isn't"), while `HaveConditionByPredicate` took the condition description. Now they both take the condition description to derive the class name.
Signed-off-by: Peter Gafert <peter.gafert@tngtech.com>
codecholeric
force-pushed
the
add-API-to-create-ArchConditions-from-predicates
branch
from
e349294 to
2cc486e
Compare
hankem
approved these changes
Jul 9, 2022
archunit/src/test/java/com/tngtech/archunit/lang/syntax/elements/MembersShouldTest.java
Show resolved
Hide resolved
archunit/src/main/java/com/tngtech/archunit/base/DescribedPredicate.java
Outdated
Show resolved
Hide resolved
archunit/src/main/java/com/tngtech/archunit/lang/conditions/ArchConditions.java
Outdated
Show resolved
Hide resolved
archunit/src/main/java/com/tngtech/archunit/lang/conditions/ArchConditions.java
Show resolved
Hide resolved
archunit/src/main/java/com/tngtech/archunit/lang/ArchCondition.java
Outdated
Show resolved
Hide resolved
archunit/src/main/java/com/tngtech/archunit/lang/ArchCondition.java
Outdated
Show resolved
Hide resolved
archunit/src/main/java/com/tngtech/archunit/lang/ArchCondition.java
Outdated
Show resolved
Hide resolved
archunit/src/main/java/com/tngtech/archunit/lang/ArchCondition.java
Outdated
Show resolved
Hide resolved
archunit/src/main/java/com/tngtech/archunit/lang/ArchCondition.java
Outdated
Show resolved
Hide resolved
archunit/src/test/java/com/tngtech/archunit/lang/ArchConditionTest.java
Outdated
Show resolved
Hide resolved
So far there has not been any straight forward way to turn a `DescribedPredicate` into an `ArchCondition`, even though the semantics are fairly similar (both determine if elements match a certain condition). The reason is, that `ArchCondition` needs more information than `DescribedPredicate`. While `DescribedPredicate` only needs to have some description to be displayed as part of the `ArchRule` text, `ArchCondition` additionally needs to describe each single event/violation that occurs. And the way how to do this depends on the predicate (take e.g. "does not *have* simple name 'Demo'" vs "is no enum" or "does not reside in a package 'com.demo'"). Thus, we have created a generic factory method `ArchCondition.from(predicate)` and two more convenient "sentence-like" factory methods `ArchConditions.{have/be}(predicate)` that can be used for most common cases. In any case if the event description does not fit it is possible to adjust it via `ConditionByPredicate.describeEventsBy(..)`.
Signed-off-by: Ulf Dreyer <ulf.dreyer@gmx.de>
Signed-off-by: Peter Gafert <peter.gafert@tngtech.com>
codecholeric
force-pushed
the
add-API-to-create-ArchConditions-from-predicates
branch
from
450c1bd to
19839a1
Compare
codecholeric
deleted the
add-API-to-create-ArchConditions-from-predicates
branch
|
This is huge, for the 1.0.0 Release I am definetly going to donate and if time let's me even contribute to this lovely project. |
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.
So far there has not been any straight forward way to turn a
DescribedPredicateinto anArchCondition, even though the semantics are fairly similar (both determine if elements match a certain condition). The reason is, thatArchConditionneeds more information thanDescribedPredicate. WhileDescribedPredicateonly needs to have some description to be displayed as part of theArchRuletext,ArchConditionadditionally needs to describe each single event/violation that occurs. And the way how to do this depends on the predicate (take e.g. "does not have simple name 'Demo'" vs "is no enum" or "does not reside in a package 'com.demo'"). Thus, we have created a generic factory methodArchCondition.from(predicate)and two more convenient "sentence-like" factory methodsArchConditions.{have/be}(predicate)that can be used for most common cases. In any case if the event description does not fit it is possible to adjust it viaConditionByPredicate.describeEventsBy(..).Issue: #855