transitivelyDependOnClasses unusable with frameworks

[To6i]

ArchUnit 0.19.0 introduced the assertion transitivelyDependOnClassesThat() (see #575).

Unfortunately the assertion is unusable when dealing with dependencies to a big framework / SDK which have a lot of dependencies within itself. Consider the following example:

• MyClass (package com.mypackage)
  • depends on OtherClass
• OtherClass (package com.intermediatepkg)
  • depends on FrameworkClass1
• FrameworkClass1 (package com.framework)
  • depends on FrameworkClass2
  • depends on FrameworkClass3
• FrameworkClass2 (package com.framework)
• FrameworkClass3 (package com.framework)

If I want to ensure that the my code in com.mypackage has no (direct or indirect) dependencies to any class within com.framework, transitivelyDependOnClassesThat() will report the following dependencies as violations:

• OtherClass -> FrameworkClass1
• FrameworkClass1 -> FrameworkClass2
• FrameworkClass1 -> FrameworkClass3

The report is unusable as MyClass does not even show up, but all dependencies within the framework / SDK itself.

In our case we want to ensure that a specific layer does not have any dependencies to the Android SDK. But Android has thousands of dependencies within itself. So if a single class has an indirect dependency to one Android class, we sometimes end up with multiple thousands (!) of violations with only one root cause. And the root cause (class) is not even visible.

In order to be helpful, transitivelyDependOnClassesThat() should report:

1. the outgoing dependency path from the checked layer / classes down to the violation
2. stop reporting any further violations when its based on the same outgoing dependency

[codecholeric]

Thanks for raising this issue! I understand why this is no good behavior in this case. We'll think about it, how this can be improved.

In the meantime, you could maybe also solve your problem by simply defining a stricter net of rules so that you don't need transitive dependencies at all. I.e. if you define for each of your layers exactly which other layer (and only that layer) may access it, and you also define which layers exactly may access the Android SDK, then there is also no way that the layer you want independent can transitively depend on Android. At least as long as the structure of the layers is set up correctly. This can for example be done fairly concise like this https://www.archunit.org/userguide/html/000_Index.html#_layer_checks (and maybe a separate rule to define the allowed dependency origins to the Android SDK)

[Pfoerd]

@codecholeric we built a customAnyTransitiveDependencyCondition extends ArchCondition for this use case. I could raise a PR if you are interested in it?

It works like this: If you have a rule noClasses().that(match(“de.foo.service..”)).should(haveAnyTransitiveDependencyToClassesIn("android.."))

Then this Architecture

would output the following violations:

java.lang.AssertionError: Architecture Violation [Priority: MEDIUM] - Rule 'no classes that match 'de.foo.service..' should transitively depend on a class that reside in any package ['android..'] was violated (3 times):
Class <de.foo.service.B> accesses <F> which transitively accesses e.g. <android.I> <- <E> <- <F>
Class <de.foo.service.B> accesses <E> which transitively accesses e.g. <android.I> <- <E>
Class <de.foo.service.C> accesses <D> which transitively accesses e.g. <android.H> <- <D>

The implementation is very efficient as it only discovers one transitive path for each direct dependency. Of course it is less verbose in it's output because it does not report all "violating" dependency paths but for most of the use cases it is good enough to know all direct dependencies that cause a transitive dependency instead of the whole transitive dependency path.

[Pfoerd]

@codecholeric, do you have time for some feedback on my suggested solution? Thanks!

[codecholeric]

Oh sorry, I must have overlooked this 🙈 This looks actually quite nice 👍 😃 So yeah, sure, I'd be interested in adding this! Would you add it as a separate ArchCondition only or also add it to the fluent API? Also wondering if it would be much trouble to offer it (additionally?) with a signature

haveAnyTransitiveDependencyToClassesThat(predicate)

I would guess internally that shouldn't make much difference, since residing in a package is also just a predicate? Because then the condition would be even more flexible 🙂

[Pfoerd]

Thank you for your response! I like your suggested improvements. The "deep" integration via extending the fluent API shouldn't be a problem, nor the additional predicate based signature. I will raise a PR 👍 .