Implement an annotation processor that issues compiler errors

[thombergs]

As suggested by @olivergierke, an AnnotationProcessor checking the module dependencies at compile-time would be awesome.

Implementing an AnnotationProcessor is easy enough. However, the current model classes (Module, Modules etc.) depend on ArchUnit to do the dependency checks. As @codecholeric pointed out, ArchUnit needs compiled classes to work, which are not yet available during annotation processing. At annotation processing time we only have access to Java's Element objects which contain information about the classes about to be compiled (TypeElement, PackageElement etc.).

So, we need to find a way to do the dependency checks based on those Element objects.

Maybe we can map those Elements to ArchUnit's domain objects and then use ArchUnit for the dependency check after all? Just a naive thought, I haven't really thought this through... .

[gunnarmorling]

Hey, just came across this one; I'm wondering whether not Deptective could be used to enforce the Moduliths rules. Either by deriving a deptective.json file (which describes allowed/disallowed package dependencies) from a Moduliths app, or if that's not expressive enough, by extending Deptective so that it could be customized with implementations of specific rule sets such as those of Moduliths. Note Deptective is a javac plug-in and as such can access the whole AST under compilation, whereas an AST wouldn't allow you to spot unwanted references from a local variable for instance.

[odrotbohm]

Thanks for chiming in, Gunnar. I'd love to explore options of how we can make this work by leveraging existing projects and APIs to not reinvent the wheel. Here are some design constraints and questions that we face (not prioritized in any kind of order).

The verification currently involves a classpath scan and ArchUnit execution to do the heavy lifting for us. That takes a bit of time. I guess some of the verifications (which are likely to be the important ones) could probably be replicated via some other tooling. In the end it's the structure of the codebase and a few annotations on the packages that define the module model. Finding cycles and invalid dependencies between those can likely be mapped to allowed package and type dependencies.

As indicated, for this analysis we need to have access to the complete class' and package space of the project which made APT an inadequate tool for this kind of analysis. Using some integration in the compile process would still be desirable though as I would've hoped that this would allow us to prevent the need for IDE specific integration as we could expose architectural violations as compile errors or warnings.

Does that help clearing the picture a bit? I wouldn't mind to jump on a 1:1 exchange to talk about details.

[gunnarmorling]

Using some integration in the compile process would still be desirable though as I would've hoped that this would allow us to prevent the need for IDE specific integration as we could expose architectural violations as compile errors or warnings.

Yes, Deptective would pretty much give you that. It hooks into the compilation process as a plug-in for javac (which also is a disadvantage, it won't work with ecj atm.) and has access to the complete AST up to the lowest level. It can produce errors/warnings when detecting any unwanted reference/dependency.

The "model" of allowed dependencies currently is expressed solely by means of package naming patterns in a JSON file (see the README in the repo for an example). It shouldn't be too hard though (and has been on my wishlist for a while) to make this more expressive via annotations e.g. representing stereotypes of defined architectural elements.

I wouldn't mind to jump on a 1:1 exchange to talk about details.

Sure, great idea. I'm pretty packed this week, how about some time early next week?