[
https://issues.apache.org/jira/browse/FLINK-34669?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jane Chan updated FLINK-34669:
------------------------------
Affects Version/s: 1.20.0
> Optimization of Arch Rules for Connector Constraints and Violation File
> Updates
> -------------------------------------------------------------------------------
>
> Key: FLINK-34669
> URL: https://issues.apache.org/jira/browse/FLINK-34669
> Project: Flink
> Issue Type: Improvement
> Components: Test Infrastructure
> Affects Versions: 1.20.0
> Reporter: Jane Chan
> Priority: Major
>
> Description:
> I have identified potential areas for optimization within our Arch rules that
> could improve our development workflow. This originated from the discussion
> for PR https://github.com/apache/flink/pull/24492
> 1. Connector Constraints:
> Our current Arch rule, `CONNECTOR_CLASSES_ONLY_DEPEND_ON_PUBLIC_API`, was
> implemented to prevent internal code changes in Flink from affecting the
> compilation of connectors in external repositories. This rule is crucial for
> connectors that are external, but it may be unnecessarily restrictive for the
> filesystem connector, which remains within the same code repository as Flink.
> Maybe we should consider excluding the filesystem connector from this rule to
> better reflect its status as an internal component.
> 2. Preconditions Class Promotion:
> The majority of Arch rule violations for connectors are related to the use of
> `Preconditions#checkX`. This consistent pattern of violations prompts the
> question of whether we should reclassify `Preconditions` from its current
> internal status to a `Public` or `PublicEvolving` interface, allowing broader
> and more official usage within our codebase.
> 3. Violation File Updates:
> Updating the violation file following the `freeze.refreeze=true` process
> outlined in the readme proves to be difficult. The diffs generated include
> the line numbers, which complicates the review process, especially when
> substantial changes are submitted. Reviewers face a considerable challenge in
> distinguishing between meaningful changes and mere line number alterations.
> To alleviate this issue, I suggest that we modify the process so that line
> numbers are not included in the violation file diffs, streamlining reviews
> and commits.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
