Expose architectural concepts via ArchUnit ArchCondition for use in custom verifications

[jamietanna]

I'm planning on writing ArchUnit tests that validate i.e.:

  @ArchTest
  @SuppressWarnings("unused")
  ArchRule mockMvcShouldOnlyBeUsedInInterfaceLayer =
      classes()
          .that()
          .areAnnotatedWith(AutoConfigureMockMvc.class)
          .should()
          .resideInAPackage("..interfaces.."); // this is the `@InterfaceLayer`

However, you'll notice that the package name here is a String, whereas it'd be ideal to reference the annotated package.

As this isn't possible, and as I'd also like to be able to TDD the migration to the new layered architecture, it'd be good to write a test that validates the @InterfaceLayer is on the same value as the package picked up by "..interfaces..".

However, as the annotations are only CLASS which means we can't pick them up at runtime through Reflection.

Is there any reason they're only CLASS, not RUNTIME?

[odrotbohm]

I think this is a matter of us providing references to concepts like "resides in Interface layer" as ArchCondition via our APIs so that you can hand them into the ….should(…) method.

Note that the annotation retention doesn't make a difference here, as ArchUnit is reading the class file information via ASM, not reflection. We so far didn't see a need to raise that level to runtime, as there's currently nothing that would evaluate these annotations via reflection.