Optimize Platform artifacts for most commonly used cases #5230
Comments
mshabarov
changed the title
manolo
changed the title
|
Thanks for reconsidering the current implementation! Really appreciated!
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. |
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). |
|
Sometimes things break in the most unexpected ways, better safe than sorry :) |
|
This ticket describes a broad vision based on introducing some new principles:
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:
|
|
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... |
a minor version to be more exact! |
|
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. |
|
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. |
|
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. |
|
@mshabarov / @Legioth / @mstahv How is this going? Vaadin 24.5 is going to hit beta soon and there was no real change in the platform artefacts as far as I've seen. Is this postponed? |
|
My impression is that we got all the desperately needed adjustments done already for 24.4 and what remains is more in the "maybe for the next major version or maybe not at all" category. Or is there some specific issue that you still think would need to be addressed right away? |
|
Well.. we still have to use multiple exclusions so that hilla does not creep up in our flow projects |
|
I think this should have already be done properly for 24.4. Many Vaadin projects now look quite weird if one looks into their build files. Don't know why next major would be needed to get this fixed properly 🤷♂️ |
|
Related ticket for optimizing component-free Vaadin/Hilla development environment: vaadin/flow#19948 |
Describe your motivation
Vaadin 24.4 unifies Flow and Hilla frameworks that, among other things, means extra dependencies tree in the
com.vaadin:vaadinandcom.vaadin:vaadin-coreartifacts, 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
com.vaadin:vaadinandcom.vaadin:vaadin-coreare deprecated (in documentation and log a warning message in runtime), but not removed.com.vaadin:vaadinandcom.vaadin:vaadin-core(e.g. adding Hilla intovaadin-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.flow-components(free) andflow-components-pro(commercial). These names are inline with the React components:react-components(free) andreact-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 corevaadin-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.vaadin-spring-boot-starter+flow-components-pro.vaadin-flow-quarkus-starter. Note that currently Vaadin Quarkus add-on doesn’t support Hilla so this includes only Flow dependencies.mvnthese dependencies are added, but when you runmvn package, the app is built for production.flow-reacttoflow-serverand removeflow-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:
Project Types VS Platform artifacts:
Additional context
Vaadin 24.4.0.beta1
The text was updated successfully, but these errors were encountered: