Vaadin 24 artifacts structure in some cases may lead to Maven exclusions in the projects, that aren’t optimal and clean enough, e.g. excluding Hilla or React.
Vaadin 25.0 could provide several new artifacts that 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 Spring-Boot apps:
vaadin-flow-core-spring-boot-starter - Spring Boot projects with only free components and only Flow
vaadin-core-spring-boot-starter - Spring Boot projects with only free components.
For Quarkus apps:
existing vaadin-quarkus-extension remains without changes. Alternative is to provide a new vaadin-core-quarkus-extension, but this requires a swap with the existing one regards free/commercial, which is breaking change.
For Jakarta EE apps:
we don’t provide any single artifact, but instead the smaller pieces like flow, flow-components, flow-components-pro, vaadin-cdi that can be opted in a project.
Open questions:
Shall we merge flow (exists) and flow-components (new) in a new single flow-core (or better name).
How non-Spring Boot apps would run in dev mode: if we don’t include vaadin-dev into any new artifact, then it would mean a need for dev profile, don’t know if this is acceptable for all.
Shall we make vaadin-core-quarkus-extension and swap vaadin-quarkus-extension to have commercial stuff. This would be a breaking change and we’ll better keep it as is until feature request.
Artifacts naming is not final. Any suggestions are welcome.
I’m hesitant to add even more words to the already long dependency names. Just my two cents: with the upcoming “Hilla as top level project deprecation” I would suggest the following for spring boot projects:
Why vaadin-dev(tools) as separate artefact?
It’s a commercial offering that should only be included if desired. Additionally it makes it pretty obvious for people to apply optional=true to it. Similar how spring devtools is added.
Why vaadin-hilla-spring-boot-starter as separate artefact?
It’s “deprecated” making it pretty easy for people to decide if they wanna include it or not. Migration for people from 24->25 would be as easy as adding this dependency if they still use Hilla. This would also help you to get proper statistics for people that use Hilla or not later one, because it’s not automatically included in the core.
Shall we merge flow (exists) and flow-components(new) in a new single flow-core (or better name).
Not sure if you wanna marketing flow externally… it’s an Implementation Detail imho… I would go with vaadin-core… even tho that name is gone
How non-Spring Boot apps would run in dev mode: if we don’t include vaadin-dev into any new artifact, then it would mean a need for dev profile, don’t know if this is acceptable for all.
Why would it require a profile if they could just add it as optional like suggested above?
Why vaadin-hilla-spring-boot-starter as separate artefact?
Hilla is not excluded from the platform (at least there is no yet a final decision about this, unless I missed something), so Hilla remains a “secondary” way of developing Vaadin application with the Flow being primary. Thus, we are not going to optimize for the case where a pure Hilla is wanted without e.g. Vaadin web-components and extra Flow modules, instead we are going to provide a minimal set of smaller artifacts to add. Though, this may change before final 25.0 release.
Why vaadin-dev(tools) as separate artefact?
Yes, the plan is to make it a separate artifact.
I would go with vaadin-core… even tho that name is gone
If we include flow into flow-components artifact, then this question goes away. The naming can be improved, but I’d keep flow-components as it’s aligned with existing react-components.
Why would it require a profile if they could just add it as optional like suggested above?
For Jakarta EE based projects it would perhaps be more convenient if running mvn would run the maven plugin with embedded server and adds the vaadin-dev dependency, whereas “main” dependency list will not include it.