You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@flink.apache.org by "ASF GitHub Bot (Jira)" <ji...@apache.org> on 2026/09/23 12:58:00 UTC
[jira] [Updated] (FLINK-40781) ArchUnit tests in flink-connector-jdbc don't analyse any production classes
[ https://issues.apache.org/jira/browse/FLINK-40781?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
ASF GitHub Bot updated FLINK-40781:
-----------------------------------
Labels: pull-request-available (was: )
> ArchUnit tests in flink-connector-jdbc don't analyse any production classes
> ---------------------------------------------------------------------------
>
> Key: FLINK-40781
> URL: https://issues.apache.org/jira/browse/FLINK-40781
> Project: Flink
> Issue Type: Bug
> Components: Connectors / JDBC
> Affects Versions: jdbc-3.3.0, jdbc-4.0.0, jdbc-4.1.0, jdbc-3.4.0
> Reporter: Martijn Visser
> Assignee: Martijn Visser
> Priority: Major
> Labels: pull-request-available
> Fix For: jdbc-5.0.0, jdbc-4.1.1
>
>
> Since FLINK-36009, the ArchUnit tests live in the separate flink-connector-jdbc-architecture module, and the modules they check are test dependencies of it. When the build goes beyond the test phase (CI runs `mvn clean deploy`), those dependencies resolve to jars. `ProductionCodeArchitectureTest` uses `ImportOption.DoNotIncludeArchives`, so it imports zero classes and every rule passes. Because `archunit.properties` sets `freeze.store.default.allowStoreUpdate=true`, the run also deletes all 96 frozen violations from the store. CI throws that away, which is why nobody noticed. Locally it shows up as a dirty `archunit-violations` directory after `mvn verify` or `mvn install`.
> With a plain `mvn test` the same rules see the classes and fail on violations that were never frozen. `TestCodeArchitectureTest` checks nothing in either case, because the tested modules' test classes aren't on its classpath.
> The other externalized connectors keep both tests in the module that holds the code, so their own classes are always in `target/classes`. The JDBC dialects each live in their own package (`org.apache.flink.connector.jdbc.postgres` etc.), so the same layout works here without extra import options. It also puts each module's own provided Flink dependencies on the classpath. The architecture module lacks `flink-runtime` and the table API, so the lineage API and `DataStream` show up there as non-public.
> Proposal: move `ProductionCodeArchitectureTest` and `TestCodeArchitectureTest` into core and each dialect module, freeze the current violations per module on the lowest Flink version in the CI matrix, and remove the architecture module plus the unused store in flink-connector-jdbc-core. Fixing the violations themselves (legacy `SinkFunction` in the SQL sink, `InitContext` in `JdbcWriter`, the `@PublicEvolving` signatures) goes in follow-up tickets.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)