You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A number of issues have noted the verbosity of failures and this is a problem for us as well for cycles at package level introduced by one small change.
Let me explain my use-case. The way that I want to use acyclic is to enforce a hexagonal architecture at the package level.
We have three package hierarchies in services, domain, application and infrastructure. domain is not allowed to have external dependencies, application is allowed to use domain and `infrastructure is allowed to use both the other two. It's an onion architecture basically.
I was really neatly able to achieve this functionality with
This prevents cycles. The problem is that the moment a cycle is introduced (eg one class in domain package depends on infrastructure) the errors reported are,
the domain class depending on infrastructure
every single infrastruture class that depends on domain package (usually hundreds)
it could be hard to spot the cause of the problem as it is only one (although it does always seem to be at the top).
What would be nice is if the report described the package cycle violations at a top level with one example but didn't print all the other hundreds of violations (the same way that it doesn't currently print more than one violation per file).
It could be something like,
[error] Unwanted cyclic dependency between uk/co/boostpower/debt/domain and uk/co/boostpower/debt/infrastructure
[error] uk/co/boostpower/debt/domain depends on uk/co/boostpower/debt/infrastructure
[info] /home/circleci/project/debt/src/main/scala/uk/co/boostpower/debt/domain/entities.scala:16:19:
[info] case class Phooey(fooBar: FooBar)
[info] ^
[info] symbol: class FooBar
[info] More dependencies in file /home/circleci/project/debt/src/main/scala/uk/co/boostpower/debt/domain/entities.scala at lines 7 7
[info] uk.co.boostpower.debt.infrastructure depends on uk/co/boostpower/debt/domain
[info] /home/circleci/project/debt/src/main/scala/uk/co/boostpower/debt/infrastructure/BalanceServiceRestClient.scala:11:8:
[info] import uk.co.boostpower.debt.domain.balance.BalanceService
[info] ^
[info] symbol: value <import>
[info] More dependencies in file /home/circleci/project/debt/src/main/scala/uk/co/boostpower/debt/infrastructure/BalanceServiceRestClient.scala at lines 7 7
[info] More dependencies in file /home/circleci/project/debt/src/main/scala/uk/co/boostpower/debt/infrastructure/Storage.scala at lines 21 12
[info] More dependencies in file /home/circleci/project/debt/src/main/scala/uk/co/boostpower/debt/infrastructure/Reporting.scala at lines 100 123
[....] you get the idea...
The text was updated successfully, but these errors were encountered:
A number of issues have noted the verbosity of failures and this is a problem for us as well for cycles at package level introduced by one small change.
Let me explain my use-case. The way that I want to use acyclic is to enforce a hexagonal architecture at the package level.
We have three package hierarchies in services,
domain
,application
andinfrastructure
.domain
is not allowed to have external dependencies,application
is allowed to usedomain
and `infrastructure is allowed to use both the other two. It's an onion architecture basically.I was really neatly able to achieve this functionality with
This prevents cycles. The problem is that the moment a cycle is introduced (eg one class in domain package depends on infrastructure) the errors reported are,
it could be hard to spot the cause of the problem as it is only one (although it does always seem to be at the top).
What would be nice is if the report described the package cycle violations at a top level with one example but didn't print all the other hundreds of violations (the same way that it doesn't currently print more than one violation per file).
It could be something like,
The text was updated successfully, but these errors were encountered: