Dennis-Mircea Ciupitu created FLINK-40107:
---------------------------------------------
Summary: 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
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)
