Release versions not immutable

[johndevs]

Currently if I decide to use version 1.0.0 of flow I would presume that the components that that version uses does not change from day-to-day, that would not really work for production builds.

However, currently if I use Flow 1.0.0 the dependencies can change at any time without nobody noticing breaking my app in production.

Here is an example of a dependency resolution of Grid (you can pick any component, it is all the same for all of them):

com.vaadin:vaadin-grid-flow:1.0.0
|    |    |    +--- org.webjars.bowergithub.vaadin:vaadin-grid:5.0.4
|    |    |    |    +--- org.webjars.bowergithub.polymerelements:iron-scroll-target-behavior:[2.0.0,3) -> 2.1.1 (*)
|    |    |    |    +--- org.webjars.bowergithub.vaadin:vaadin-element-mixin:[1.0.1,2) -> 1.1.1 (*)
|    |    |    |    +--- org.webjars.bowergithub.vaadin:vaadin-lumo-styles:[1.0.0,2) -> 1.1.0-alpha3 (*)
|    |    |    |    +--- org.webjars.bowergithub.polymerelements:iron-resizable-behavior:[2.0.0,3) -> 2.1.1 (*)
|    |    |    |    +--- org.webjars.bowergithub.polymerelements:iron-a11y-keys-behavior:[2.0.0,3) -> 2.1.1 (*)
|    |    |    |    +--- org.webjars.bowergithub.polymer:polymer:[2.0.0,3) -> 2.6.0 (*)
|    |    |    |    +--- org.webjars.bowergithub.vaadin:vaadin-checkbox:[2.0.0,3) -> 2.1.1 (*)
|    |    |    |    +--- org.webjars.bowergithub.vaadin:vaadin-themable-mixin:[1.1.0,2) -> 1.2.0 (*)
|    |    |    |    +--- org.webjars.bowergithub.polymerelements:iron-a11y-announcer:[2.0.0,3) -> 2.1.0 (*)
|    |    |    |    \--- org.webjars.bowergithub.vaadin:vaadin-text-field:[2.0.0,3) -> 2.0.1 (*)
|    |    |    +--- org.webjars.bowergithub.polymerelements:iron-flex-layout:2.0.3 (*)

As you can see due to the ranges in the dependency definitions the dependencies change immediately when a component releases a new version. What is worse is that it seems to be pulling in alpha versions into the stable release as well.

Please use stable version numbers for releases and bump them in a release, rather than using ranges making everyone trying to maintain a Vaadin app a nightmare. Thanks!

[mvysny]

The Vaadin BOM locks the versions on an exact version number as can be seen here: http://search.maven.org/#artifactdetails%7Ccom.vaadin%7Cvaadin-bom%7C10.0.1%7Cpom The version ranges come from the way how the dependencies are defined with npm or whatever JavaScript thing; a webjar must probably honor the dependency versions, even if they are ranges (which is quite unfortunate, I agree). BOM is probably a workaround, a hack for borked dependencies, but it works quite nicely and prevents your dependencies from auto-upgrading.

To use BOM with Gradle, you need to put the following into your build.gradle:

plugins {
    id "io.spring.dependency-management" version "1.0.4.RELEASE"
}
dependencyManagement {
    imports { mavenBom "com.vaadin:vaadin-bom:$vaadin10_version" }
}

For a very simple example project please check out https://github.com/mvysny/karibu10-helloworld-application

Gradle contains BOM mechanism but unfortunately it doesn't seem to work properly with Vaadin BOM: https://github.com/gradle/gradle/issues/4417

[johndevs]

Yes, it can be worked around in several ways, here are a few:

• Using the Spring dependency management plugin (which has the side effect of add yet-another dependency resolution layer on top of Gradles own)
• Using the Dependency locking functionality introduced in 4.9 (https://docs.gradle.org/current/userguide/dependency_locking.html)
• Using a ResolutionStrategy that resolves the version ranges into specific versions or wildcard versions (this is what the https://github.com/devsoap/gradle-vaadin-flow currently does)

But these are all work-arounds for inherently a problem in the framework version management that needs to be solved on that level.

[johndevs]

The main problem as I see is the use of non-versioned dependencies in the flow-components (for example https://github.com/vaadin/vaadin-split-layout-flow/blob/master/pom.xml).

This will make for example vaadin-split-layout-flow 1.0.0 to mean one set of components today, and after a month another set of components. vaadin-split-layout-flow 1.0.0 is acting as a dynamic version right now that basically never needs to be updated as the underlaying components upgrade.

Ultimately this means that it is impossible to re-produce a build that was made with vaadin-split-layout-flow 1.0.0 as you would need to figure out exactly what dependencies were used at that time.

Dependency versions should be resolved at build time, not runtime, the reasoning is exactly the same as you prefer build time exceptions rather than runtime exceptions when building Java apps.

[SomeoneToIgnore]

Hello, we've fixed the all the WebJar's versions for every component, no alpha versions are used also for Vaadin 10.

You can verify this by looking at the dependency tree of any component for the 1.0 branch.

For instance, the same vaadin-split-layout: https://github.com/vaadin/vaadin-split-layout-flow/blob/1.0/pom.xml

Uses this pom as a parent: https://github.com/vaadin/flow-component-base/blob/1.0/pom.xml Thus getting the following dependency tree always (no more ranges):

[INFO] --- maven-dependency-plugin:2.8:tree (default-cli) @ vaadin-split-layout-flow ---
[INFO] com.vaadin:vaadin-split-layout-flow:jar:1.0-SNAPSHOT
[INFO] +- org.webjars.bowergithub.vaadin:vaadin-split-layout:jar:4.0.1:compile
[INFO] +- org.webjars.bowergithub.vaadin:vaadin-element-mixin:jar:1.0.2:compile
[INFO] +- org.webjars.bowergithub.vaadin:vaadin-usage-statistics:jar:1.0.8:compile
[INFO] +- org.webjars.bowergithub.vaadin:vaadin-development-mode-detector:jar:1.0.3:compile
[INFO] +- org.webjars.bowergithub.vaadin:vaadin-lumo-styles:jar:1.0.0:compile
[INFO] +- org.webjars.bowergithub.polymerelements:iron-icon:jar:2.1.0:compile
[INFO] +- org.webjars.bowergithub.polymerelements:iron-meta:jar:2.1.1:compile
[INFO] +- org.webjars.bowergithub.polymerelements:iron-iconset-svg:jar:2.2.1:compile
[INFO] +- org.webjars.bowergithub.polymerelements:iron-resizable-behavior:jar:2.1.1:compile
[INFO] +- org.webjars.bowergithub.vaadin:vaadin-themable-mixin:jar:1.1.6:compile
[INFO] +- org.webjars.bowergithub.polymerelements:iron-flex-layout:jar:2.0.3:compile
[INFO] +- com.vaadin:flow:pom:1.0-SNAPSHOT:provided
    ---- contents is omitted for brevity, no WebJars here ----
[INFO] +- org.webjars.bowergithub.polymer:polymer:jar:2.6.0:compile
[INFO] +- org.webjars.bowergithub.webcomponents:webcomponentsjs:jar:1.2.2:compile
[INFO] \- org.webjars.bowergithub.webcomponents:shadycss:jar:1.2.1:compile

Similar thing is in the master branch, but there are alphas in the dependencies, since this branch is now serves as a base for the new Vaadin version.

We'll release the new versions this week, so the problem will be fixed soon.

[johndevs]

@SomeoneToIgnore Did this also fix vaadin-lumo-styles? it previously had a range defined for shadycss that is pulling in a non-bower compatible version.

A user of the gradle plugin recently had to downgrade because of this (devsoap/gradle-vaadin-flow/issues/74):

I have to downgrade shadycss to version 1.2.1 because the current version does not ship bower.json which causes another build failure."

[SomeoneToIgnore]

Yes, we have are also fixed those WebJars and now vaadin-lumo-styles use fixed shadycss of version 1.2.1 It's in the corresponding 1.0 branch also, the release will follow.

[johndevs]

@SomeoneToIgnore Excellent, thanks!

[mvysny]

@SomeoneToIgnore if I understand correctly, there is going to be a Vaadin 10 10.0.2 release which will contain fixed dependency versions, and hence the BOM will no longer be necessary to be applied?

[SomeoneToIgnore]

there is going to be a Vaadin 10 10.0.2 release which will contain fixed dependency versions

That is true.

hence the BOM will no longer be necessary to be applied

Well, yes and no. It is not needed anymore for fixing the WebJar dependency ranges, but it is still useful when you want to add more platform dependencies like production mode support or Spring support or whatnot – the bom contains all the version definitions needed and provides guarantees that those versions work together seamlessly.

[johndevs]

@mvysny After the Webjars have been fixed the Vaadin BOM should also work with Gradle's experimental BOM support, the only problem with it so far that I am aware of has been those dependency ranges.

For reference how to use the Vaadin BOM with the Gradle plugin, see https://github.com/devsoap/gradle-vaadin-flow/wiki/Dependency-management

[Legioth]

Is there still anything that should be done in the scope of this issue?

[SomeoneToIgnore]

Right, this one is fixed.