[
https://issues.apache.org/jira/browse/FLINK-40107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated FLINK-40107:
-----------------------------------
Labels: pull-request-available (was: )
> Group example modules under an examples aggregator pom
> ------------------------------------------------------
>
> Key: FLINK-40107
> URL: https://issues.apache.org/jira/browse/FLINK-40107
> Project: Flink
> Issue Type: Improvement
> Components: Kubernetes Operator
> Affects Versions: kubernetes-operator-1.15.0
> Reporter: Dennis-Mircea Ciupitu
> Priority: Major
> Labels: pull-request-available
>
> h1. Summary
> Group the example modules under a dedicated {{examples}} aggregator pom
> instead of listing each of them individually in the parent {{pom.xml}}. The
> parent would then reference a single {{examples}} module, and the aggregator
> would own the list of example modules and their shared configuration.
> h1. Motivation
> The parent {{pom.xml}} currently lists the four example modules directly
> alongside the eight core modules:
> * {{examples/flink-sql-runner-example}}
> * {{examples/flink-beam-example}}
> * {{examples/kubernetes-client-examples}}
> * {{examples/autoscaling}}
> This has a few downsides:
> * The parent pom has to be edited every time an example is added or removed,
> mixing example bookkeeping with the core module list.
> * Configuration common to all examples is duplicated. Each example pom
> independently sets {{maven.deploy.skip=true}}, since examples are not
> published.
> * There is no single place that represents "the examples" as a unit, which
> makes it harder to build or skip them together.
> Apache Flink itself uses this pattern via its {{flink-examples}} aggregator
> module, so there is established precedent in the ecosystem.
> h1. Proposed change
> Introduce an {{examples/pom.xml}} aggregator module (packaging {{pom}}) whose
> parent is {{flink-kubernetes-operator-parent}}. It would:
> * Declare the four example modules in its own {{modules}} section.
> * Own the shared example configuration, most notably
> {{maven.deploy.skip=true}}, so it is defined once and inherited.
> The parent {{pom.xml}} would then reference only the single {{examples}}
> module, and each example would use the new aggregator as its parent. Because
> the aggregator inherits from the root parent, all existing managed
> dependencies, plugin configuration, and properties (for example
> {{flink.version}}) continue to resolve unchanged.
> h1. Benefits
> * The parent pom no longer changes when examples are added or removed.
> * Shared example configuration lives in one place rather than being
> duplicated per example.
> * The examples become addressable as a unit for building or skipping.
> h1. Out of scope / open question
> This change is purely structural and does not, by itself, remove the examples
> from the default reactor build, they are still built and shown in the reactor
> summary. Making the examples opt-in (for example behind a profile) is a
> separate decision with a CI tradeoff, since CI would then need to opt in to
> keep validating them. That should be discussed separately rather than bundled
> into this refactor.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
