Explain the difference between StreamPark's convention-over-configuration approach and manually configuring a Flink project?

The difference isn't in what's ultimately possible — both approaches can express the same Flink job — but in how many decisions a developer has to make explicitly before anything runs.

A manually configured Flink project starts from a blank slate: project structure, dependency versions, environment setup code, connector boilerplate, and configuration file format are all decisions the developer makes fresh, or copies from whatever the last project happened to do. This is maximally flexible, but it also means every project can end up structured differently, and knowledge about "how we normally set this up" lives in people's heads or scattered documentation rather than in the tooling itself.

StreamPark Core's convention-over-configuration approach instead ships opinionated defaults for most of that: a standard project layout, a RuntimeContext that already builds a correctly configured execution environment, and a connector library so common sources/sinks don't need boilerplate. A developer only writes configuration for the things that genuinely differ between jobs — business logic, connector endpoints, resource sizing — while the repetitive setup work is inherited from the framework's conventions.

The trade-off is the classic one for any opinionated framework: less flexibility for genuinely unusual setups, in exchange for faster ramp-up, more consistency across a team's projects, and fewer copy-paste errors from one project's boilerplate to the next.