Hi everyone, I'm happy to announce now that we finished this test and it has been merged (thanks to Chesnay for his help here). You can also find some documentation for it here[1]. I haven't implemented all of the suggested rules, but we can of course expand our checks here. The current rules show already quite a few violations, some of which I will be going through in the next weeks. They range from trivial fixes to things that need to be thought about.
[1] https://github.com/apache/flink/blob/master/flink-architecture-tests/README.md Ingo On Wed, Sep 1, 2021 at 11:03 AM Ingo Bürk <i...@ververica.com> wrote: > Hello everyone, > > I would like to start a discussion on introducing automated tests for more > architectural rather than stilistic topics. For example, here are a few > things that seem worth checking to me (this is Table-API-focused since it > is the subsystem I'm involved in): > > (a) All classes in o.a.f.table.api should be annotated with one > of @Internal, @PublicEvolving, or @Public. > (b) Classes whose name ends in *ConnectorOptions should be located in > o.a.f.connector.*.table > (c) Classes implementing DynamicSourceFactory / DynamicSinkFactory should > have no static members of type ConfigOption > > There are probably significantly more cases worth checking, and also more > involved ones (these are rather simple examples), like disallowing access > between certain packages etc. There are two questions I would like to ask > to the community: > > (1) Do you think such tests are useful in general? > (2) What use cases come to mind for you? > > If the idea finds consensus, I would like to use (2) to investigate which > tooling to use. An obvious candidate is Checkstyle, as this is already > used. It also has the advantage of being well integrated in the IDE. > However, it is limited to looking at single files only, and custom checks > are pretty complicated and involved to implement[1]. Another possible tool > is ArchUnit[2], which would be significantly easier to maintain and is more > powerful, but in turn requires tests to be executed. If you have further > suggestions (or thoughts) they would of course also be quite welcome, > though for now I would focus on (1) and (2) and go from there to evaluate. > > [1] https://checkstyle.sourceforge.io/writingchecks.html > [2] https://www.archunit.org/ > > > Best > Ingo >
