Automatically resolving transitive class dependencies with the following configuration: is logged *a lot* in 0.23.0

[famod]

For a simple test I'm seeing this multiple times:

2022-02-20 12:47:59,624 INFO  [com.tng.arc.cor.imp.DependencyResolutionProcess] (main) Automatically resolving transitive class dependencies with the following configuration:
import.dependencyResolutionProcess.maxIterationsForMemberTypes = 1
import.dependencyResolutionProcess.maxIterationsForAccessesToTypes = 1
import.dependencyResolutionProcess.maxIterationsForSupertypes = -1
import.dependencyResolutionProcess.maxIterationsForEnclosingTypes = -1
import.dependencyResolutionProcess.maxIterationsForAnnotationTypes = -1
import.dependencyResolutionProcess.maxIterationsForGenericSignatureTypes = -1

To me it looks as if this should only be logged once or/and only with DEBUG?

[codecholeric]

That is strange, it should only be logged one time and when I test this locally it also is 🤔 I mean, it is logged one time for every import. Do you see it multiple times for a single call of ClassFileImporter.import...?
In any case, maybe DEBUG level is fair, to me it seemed like the logging of where the archunit.properties is read from, but I guess it's a finer level, because it's not relevant for typical use cases. Guess I'll change it to DEBUG...
If it's annoying to you you can simply set DependencyResolutionProcess to WARN though for now...

[famod]

We have multiple AU test classes and thus multiple @AnalyzeClasses, which I think explains it.

Switching to DEBUG would be nice, yes.

[famod]

Hum, I debugged this a little and that logging method is hit twice four times for the following test class:

@AnalyzeClasses(locations = OurCustomLocationProvider.class, importOptions = { OnlyIncludeTests.class })
class TestBasicsArchTest {

    @ArchTest
    final ArchRule doNotUseJunitAssertions = noClasses()
            .that().areNotAssignableTo(TestBasicsArchTest.class)
            .should().dependOnClassesThat().areAssignableTo(org.junit.jupiter.api.Assertions.class)
            .because("use org.assertj.core.api.Assertions instead");

    @ArchTest
    final ArchRule testMethodsShouldBePublic = ArchRuleDefinition.methods()
            .that().areMetaAnnotatedWith(Testable.class)
            .should().bePublic();
}

Is this to be expected?

[famod]

Another example: https://github.com/gitflow-incremental-builder/gitflow-incremental-builder/blob/main/src/test/java/io/github/gitflowincrementalbuilder/ArchitectureTest.java

mvn test -Dtest=ArchitectureTest yields 3 log outputs (need to switch this to INFO first: https://github.com/gitflow-incremental-builder/gitflow-incremental-builder/blob/main/src/test/resources/logback-test.xml#L25).

[codecholeric]

Hmm, I tested your examples (switching the one category to INFO again) and with Maven I see 3 log outputs, but with IntelliJ I see two log outputs 🤔
In any case, two outputs would make sense for me, because one time is for the test class (between individual runs the classes are cached) and one time is as part of the ArchUnitTestEngine. Because the TestEngine again uses ArchUnit internally to detect test classes on the classpath (in the end the JUnit platform doesn't give engine creators a lot when a DiscoveryRequest wants to run everything inside a package, so back then I decided to simply use ArchUnit again, since it makes it very easy to analyse all classes in a package for test candidates).

[codecholeric]

I debugged real quick and it looks like Maven Surefire somehow first discovers tests and then calls execute in a second step which again discovers tests 🤷‍♂️ Since it calls discover twice the engine also needs to search test classes on the classpath twice and that causes the additional logs...