Optimize Platform artifacts for most commonly used cases

[mshabarov]

Describe your motivation

Vaadin 24.4 unifies Flow and Hilla frameworks that, among other things, means extra dependencies tree in the com.vaadin:vaadin and com.vaadin:vaadin-core artifacts, which aren't always necessary and desired for projects. With the current structure this may lead to Maven exclusions in the projects, that aren't optimal and clean enough.

This feature request proposes a list of new artifacts in Vaadin Platform that should simplify picking the minimal set of Vaadin products needed for a project and allow developers to opt-in the necessary dependencies, instead of opt-out with Maven exclusions.

For the most used projects set-ups Vaadin Platform provides the "starters" dependencies, that includes all needed Vaadin dependencies for a target framework/container. From the other side, Vaadin Platform provides more granular artifacts that one can combine to build a desired configuration. The number of various Vaadin products and other frameworks, that Vaadin has integration with, may lead to the long list of different combination, but we'll focus on the key ones and assumes that for other combinations one would need to add a bit more granular artifacts, say one up to three.

Backwards compatibility is preserved, i.e. we have to preserve the old artifacts that developers are used to have, but deprecate them and recommend to use the new ones.

Acceptance Criteria

• [ ] ( 1 ) com.vaadin:vaadin and com.vaadin:vaadin-core are be deprecated (in documentation and log a warning message in runtime), but not removed.
  • [ ] ( 2 ) Changes in 24.4 regarding extra dependencies in com.vaadin:vaadin and com.vaadin:vaadin-core (e.g. adding Hilla into vaadin-core) should be reverted back, so these artifacts would be backwards compatible and not give unexpected errors or behaviour to users who upgrade to 24.4.
• [ ] ( 3 )Vaadin groups core and pro Flow components into separate dependencies, so they can be added to projects and Platform dependencies separately: flow-components (free) and flow-components-pro (commercial). These names are inline with the React components: react-components (free) and react-components-pro (commercial). Vaadin also provides “react-components” and “react-components-pro” artifacts that tell Flow whether React components should be put into package.json, and which one, pro or only core
• [ ] ( 4 ) Vaadin provides high-level dependency (let's call them "starters") that includes everything needed for developing hybrid applications with the Spring Boot, with only core components - vaadin-spring-boot-starter. This artifact reuses the old name that now with 24.4 has Hilla shipped by default. This shouldn't lead to any errors during upgrade to 24.4, not any anomalies in behavior, but some performance parameters may be a bit degraded due to extra dependencies, e.g. app startup time.
• [ ] ( 5 ) Those who want (4), but with the pro components, may use vaadin-spring-boot-starter + flow-components-pro.
• [ ] ( 6 ) Vaadin provides a single dependency for what is needed for Quarkus applications, including core components - vaadin-flow-quarkus-starter. Note that currently Vaadin Quarkus add-on doesn’t support Hilla so this includes only Flow dependencies.
• [ ] ( 7 ) React components are added into (4) and (5).
• [ ] ( 8 ) Development mode dependencies are grouped into one dependency and are opt-in options that can be added to Maven profile, if needed, i.e. when you run mvn these dependencies are added, but when you run mvn package, the app is built for production.
• [ ] ( 9 ) Move react adapter classes from flow-react to flow-server and remove flow-react, as artifacts from (3) can be used as markers for Flow.

Describe the solution you'd like

Preliminary structure of artifacts, starting from more granular to more high level:

Artifact Name	Artifacts Included
flow-components	Would contain only the free flow components (react core components are not JAR dependencies and added by Flow separately from maven structure)
flow-components-pro	Would contain only pro components (react pro components are not JAR dependencies and added by Flow separately from maven structure)
react-components	Free React Components
react-components-pro	Commercial React Components
flow	flow-server, flow-data and etc.
vaadin-dev-flow	copilot, vaadin-dev-bundle, vaadin-dev-server
vaadin-dev-hilla	copilot, hilla-dev, vaadin-dev-server
vaadin-dev	vaadin-dev-flow, vaadin-dev-hilla
vaadin-flow-core-spring-boot-starter	flow, flow-components, vaadin-spring, spring-boot-starter-web
vaadin-hilla-core-spring-boot-starter	hilla, react-components
vaadin-flow-quarkus-starter	flow, flow-jandex, flow-components, vaadin-quarkus-extension
vaadin-spring-boot-starter	vaadin-hilla-core-spring-boot-starter, vaadin-flow-core-spring-boot-starter

Project Types VS Platform artifacts:

Project Type	Dependencies	Optional Dependencies
Spring Initializer	vaadin-core-spring-boot-starter	flow-components-pro, react-components-pro, vaadin-dev
Quarkus Extension Directory	vaadin-flow-quarkus-starter	flow-components-pro, vaadin-dev-flow
Flow Spring Boot skeleton	vaadin-flow-core-spring-boot-starter	flow-components-pro, vaadin-dev-flow
Flow Jakarta EE skeleton	flow, vaadin-cdi, flow-components	flow-components-pro, vaadin-dev-flow
Flow plain servlets	flow, flow-components	flow-components-pro, vaadin-dev-flow
Hilla React	vaadin-hilla-core-spring-boot-starter	react-components-pro, vaadin-dev-hilla
Hilla Lit	vaadin-hilla-core-spring-boot-starter, flow-components, enableReact=false	flow-components-pro, vaadin-dev-hilla
Hybrid (Hilla + Flow + React)	vaadin-core-spring-boot-starter	flow-components-pro, react-components-pro, vaadin-dev

Additional context

Vaadin 24.4.0.beta1

[knoobie]

Thanks for reconsidering the current implementation! Really appreciated!

Move react adapter classes from flow-react to flow-server and remove flow-react

No objection, I pushed for the other module to make sure I can exclude react components - now that those get their separate maven dependency (?), this looks like a good trade-off.

Just one thing to point out, to ensure it still works: Create a Project that uses Free Components + a single Pro Component (like Charts) -> so it's possible to just include the vaadin-charts dep, instead of using all.

[Legioth]

Just one thing to point out, to ensure it still works: Create a Project that uses Free Components + a single Pro Component (like Charts) -> so it's possible to just include the vaadin-charts dep, instead of using all.

That would still work. This plan doesn't even consider the alternative of removing the individual component modules (even though they are a bit of a hassle for us internally when it comes to coordinating releases).

[knoobie]

Sometimes things break in the most unexpected ways, better safe than sorry :)

[Legioth]

This ticket describes a broad vision based on introducing some new principles:

1. Make the common cases easy: There's a small set of getting-started cases that we want to optimize for: start.vaadin.com, start.spring.io and the Quarkus directory. Optimizing means that there's a dedicated collection of dependencies specifically for that case. We don't optimize for other cases.
2. Make the other cases practical without relying on exclusions. This includes other runtime environments, dependencies intended only for development mode, optimizing deployment size by using only one of Flow or Hilla but not both, and opting out from parts with a commercial license.
3. The vaadin and vaadin-core dependencies no longer serve any purpose in the world of "starters" (e.g. entry-point artifacts with a Spring Boot autoconfiguration). We should revert them to what they were in Vaadin 24.3 and deprecate them.

The end result from following those principles leads to introducing all the new dependencies described here. This is a non-trivial amount of changes that I'm not sure we want to do right now due to effort, the risk of breaking things late in the 24.4 release cycle, and some uncertainty about the design (e.g. the possibility that Spring Boot will introduce a mechanism for automatically excluding dev dependencies from production builds). I would suggest that we instead focus on a smaller set of changes for fixing the new issues that we would otherwise introduce in 24.4, but not at this time changing all the other things as well.

The issues that are most urgent to fix right now are:

• Preserve backwards compatibility for the vaadin and vaadin-core dependencies for e.g. Quarkus users by not including Hilla in them. Instead, we add Hilla as a dependency of vaadin-spring-boot-starter. Spring Boot users who want to optimize their deployment size to not include Hilla can exclude it from that dependency.
• Include commercial dependencies only when using vaadin but not when using vaadin-core. This becomes a problem with the new React components and we fix this by splitting up the React component dependency into two parts and includes the free part as a dependency through vaadin-core and all of it in vaadin. This means that Hilla users would by default also use either vaadin or vaadin-core but they can use more fine-grained dependencies if they want to optimize (i.e. to avoid including the Flow APIs for the components).

[mshabarov]

For reference, these two issues should cover these last urgent changes: https://github.com/vaadin/platform/issues/5204 https://github.com/vaadin/platform/issues/5260

[mstahv]

As the plan is to re-adjust the modules, I don't see why we want to break all existing Spring Boot based apps. At least with current alpha releases, they all becomes bigger, slower and contains more dependencies. Many/most of these apps are in maintenance phase and essentially want to keep up with the latest bugfixes and security isseus. Nobody wants a new framework when they change the version number in the pom.xml.

There is plenty of names available. Adding a new starter with everything-and-the-kitche-sink and reverting the current starter to what it is today is the same magnitude of work. But in general, it there is this kind of module refactoring in sight, I'd do it right away, instead of publishing a stable version with slightly variant before it...

[knoobie]

wants a new framework when they change the version number

a minor version to be more exact!

[Legioth]

I'm not aware of applications getting broken if we limit the change to applications that use Spring Boot. It is true that the development setup for the application becomes bigger but it also gets more capabilities. In that way, it's similar to adding a new UI component even though many developers won't start using that UI component when they switch to the new version in an existing application with a UI design that didn't take the new UI component into account. That UI component also adds to the size even though it's certainly a smaller increase than what comes from adding Hilla.

[knoobie]

Comparing Hilla with a new component is a bold statement / far fetched comparison. Just saying: with great capability comes even greater (new) responsibility.

Hilla, official Copilot and React Router in a single minor release just feels rushed. I know most / everything can be changed / configured to justify the customer's need but changing the pom exclusions in a minor versions is not something I'm seeing often.

[Legioth]

We have indeed considered the option of releasing these changes as Vaadin 25.0.0 instead of Vaadin 24.4.0 but concluded that it would be redundant since we aren't removing any functionality.

Our guiding principle is that a minor release can introduce "trivial" breaking changes that can be dealt with using automation (e.g. search and replace for changed imports) or changes that don't scale with the size of the application (e.g. setting a flag to preserve some deprecated logic). We still need to be cautious even within those categories since e.g. a changed import also means that add-ons would have to be updated to remain compatible. We also need to be careful with documenting such cases in the release notes.