Hi all! I was trying to implement some architectu...

# konsist

[Evgeny Stroykov]

Hi all!

I was trying to implement some architecture tests with Konsist (ver. 0.15.1). I have two packages in my project — io.something.source and io.something.target. And I was trying to define layers like the following:

val source = Layer("Source", "io.something.source..")
val target = Layer("Target", "io.something.target..")

But when I add any assertion on target layer, I have the following error:

com.lemonappdev.konsist.core.exception.KoPreconditionFailedException: Layer Target doesn't contain any files.
   at com.lemonappdev.konsist.core.verify.KoArchitectureAssertKt.validateAllLayersAreValid(KoArchitectureAssert.kt:113)

(but there are some files in the corresponding package)

I've checked out Konsist source code and found isBuildOrTargetPath function which filters out any files from scope if their path contains /target/ — due to to fact that this is how Maven build directory is called. So looks like there is no any workaround in my case and it is not possible to deal with files in target package no matter how exactly I create Konsist scope, is it?

[PoisonedYouth]

Is
val mavenModuleBuildDirectoryRegex = Regex("$projectRootPath/.+/$mavenBuildDirectoryName/.*".toMacOsSeparator())
matching your package path? Have you debugged it?

[Evgeny Stroykov]

Yes, I have debugged. And yes, that regex matches my package path (the rest three ones do not).

[PoisonedYouth]

That is an interesting false positive match.

[PoisonedYouth]

The regex matches if there is a target directory anywhere in the package structure, independent in which position.
To fix this and still match the target directory of submodules you need to check the path starting from the module root instead the project root (modules can be nested).

[PoisonedYouth]

Maybe the matching logic for the target directory should also check that src is not part of the path to exclude everything below.

[Evgeny Stroykov]

To fix this and still match the target directory of submodules you need to check the path starting from the module root instead the project root

Not sure if it helps. Both desirable and undesirable target directories are under the module root directory, aren't they?

root
- module
- - src
- - - target (to be included into scope)
- - target (to be excluded from scope)

Maybe the matching logic for the target directory should also check that src is not part of the path to exclude everything below.

This would help in my case. However, I am wondering if this is a good solution in the general case, given that name of src directory is just a convention and may be overridden in a particular Maven project. I don't have any other ideas, though.

[PoisonedYouth]

Yes matching a hardcoded src directory does not feel as a good solution but I don't know how to fix this universally. As you showed above both target directories are below the same module root and only differ that one is part of the application sources and the other is the output directory of the maven build.

But aren't the target and build directory also only conventions and can be changed?

[Evgeny Stroykov]

I believe they are. In Maven, looks like it is not recommended to use another name, but still possible. Gradle must be even more flexible.

[Evgeny Stroykov]

Well, if it is possible to use the module root directory instead of the project root directory, the regex might be changed to expect target or build only at the beginning of relative url — not anywhere in the middle.

But not sure it is easy to get the module root directory there.

[Evgeny Stroykov]

Another approach might be to have some additional parameter in any function which creates scopes. And this parameter will specify a predicate to filter out some files. The default value is to filter out those which have target or build somewhere in their path.

[PoisonedYouth]

Modules can also be nested more than one level, so you possibly only can solve this by parsing them from pom.xml or settings.gradle.kts file.

[PoisonedYouth]

The approach to overwrite the filters seems like a better approach