Urgent migration needed to a newer Vaadin version

[strailov]

As you may know hawkBit uses Vaadin 8 for its user interface. Vaadin 8 reached its end of life (EOL) at 21/02/2022. Currently hawkBit depends on the latest released under Apache 2.0 license Vaadin 8 version - which is still ok. However, if a security vulnerability of that version is found - there won't be an open source fix. In that case the Vaadin based UI shall be removed from hawkBit (if still using Vaadin 8).
So the hawkBit UI shall urgently be migrated to newer Vaadin versions (e.g. 23/24), which are supported and under open source license.
Are there volunteers to implement that issue ?

[avgustinmm]

Current state

hawkBit UI uses Vaadin as a web UI framework. The currently used version is Vaadin 8 (8.14.3). This version, according Vaadin Roadmap, has no free support since 21st Feb 2022. There are some version release after that date (8.15.0 - 8.16.0) that seem to be Apache 2.0 licensed and probably could be used in hawkbBit. However, since 8.16.0 the license is Commercial Vaadin Developer License 4.0 , so they could not be used in hawkBit.

Problem

At the time being all is OK but if a security vulnerability is discovered in free versions the hawkBit will have to just drop the UI unless it is migrated to newer version of Vaadin.

There is another problem. hawkBit uses, at the moment, Spring Boot 2.7.12. According to Spring Boot EOL Spring boot 2.7 stream will reach end of support 18th Nov 2023. So, up to that date hawkBit shall be migrated to Spring Boot 3.0 / 3.1. Since Vaadin 8 seem to be incompatible with Spring Boot 3 (they added support for Spring Boot 3 in Vaadin 24 (Vaasin 24 pre release) we shall drop UI unless it is migrated to Vaadin 23.

Options

A. Migrate Vaadin to version 24

Since both, migration to Spring Boot 3.0/3.1 and Vaadin 24 are big change and challenge they shall be made as separate as possible. So the proper plan could be:

1. Migrate to Vaadin 23 (supporting Spring Boot 2.7) - huge efforts, community support is needed here.
2. Migrate in parallel to Spring Boot 3.0/3.1 (big efforts expected) and to Vaadin 24 (with Spring Boot 3 support, hopefully insignificant efforts)

All this shall be implemented by the 18th Nov 2023, so the step 1 shall be ready, let say, until 1st Nov 2023.

B. Drop hawkBit UI

If there is no community for Vaadin migration in the needed time frame we'll have to just migrate the hawkBit update server to Spring Boot 3 and drop the hawkBit UI.

It is possible that in some future time someone from the community will return back the Vaadin based UI by migrating to 24+ version or add completely new UI. But for some time, at least, hawkBit will remain without UI.

[siepkes]

I'll just leave my "2 cents" here. It might contain some useful insights.

I think the main "difficultly" is that Vaadin >= 10 (There is no Vaadin 9) is completely different from Vaadin 8. Vaadin moved away from GWT (i.e. from Java to Javascript transpilation). At the time Google created a lot of uncertainty around GWT's future (which has since been resolved). I guess Vaadin got scared and moved away from GWT. This was before it's successor, J2CL was open sourced by Google.

Depending on how Hawkbit uses Vaadin there might be no easy "upgrade" from Vaadin 8. It's almost as if you are migrating to a different framework. If you want something similar to Vaadin 8 (i.e. Java to Javascript transpilation) you are probably better of using something like DominoUI which is based on Google's GWT successor, J2CL. Or something like TeaVM.

[truedat101]

Curious what the direction is? It sounds painful. It looks like there is an industry around handling migrations between Vaadin UI versions. I am new to the HawkBit community but I have years of work in Java and Mobile Java.

• Has the team considered a fork of Vaadin UI at the point of the last OSS release? I assume the Vaadin community was either thrilled or not thrilled about the licensing change. Does an active fork actually exist? https://github.com/vaadin/framework/network ... seems not.
• Has the team looked at writing a migration tool to generate the migration to something else? I note, there exists a 7 to 8 tool. Java is really good for introspection and code generation, it could be possible. My brief search didn't turn up any tools for Vaadin UI 8 to framework ___ .
• I did find someone who went down the rabbit hole of the analysis of options: https://medium.com/@fezu54/vaadin-8-and-vue-js-a-smooth-migration-b0ef248962d and a move to vue.js

This last approach seems pragmatic. As an outside to the group, and someone who does generally hand off the web part to the "web people", the focus and energy around web UI and front end design is in JS and Typescript. Like it or hate it. It's much easier to find a volunteer to carry forward vue.js or similar. I realize it may sound like sacrilege to develop components outside of Java. It looks like there is a way to use spring boot plus vue.js anyways.

Interested in the outcome and plan.

[siepkes]

@truedat101 Interesting read.

I realize it may sound like sacrilege to develop components outside of Java.

I think the main issue with such a thing would be that the Hawkbit community consists mostly of people comfortable with languages which are often used in the back-end. Such as Java, Kotlin, Rust, etc. Meaning people comfortable with for example Typescript and Vue would need to be brought in to the project.

Personally I'm currently working on projects with htmx as an alternative to Vaadin and as a way of not doing a Typescript based SPA. The way htmx works might look weird when you first see it, but once you start using htmx it actually makes a lot of sense. One big advantage of htmx is that the community is very large because it works with any backend language (Java, Python, Ruby, etc.). Especially on the Python side there are a lot of people who would rather use Django + htmx then doing a full Typescript based SPA.

[truedat101]

I'll take a look at htmx. I've seen the pattern of "stackism" in many startups (where the leader thinks everything has to be done in only one language for simplicity or elegance or simply for the reason that they don't like the languages they don't understand deeply). The only problem with this way of thinking is that it limits who can work on the front end if it isn't html5/js/css/etc. Professional designers typically aren't comfortable with Java or other compiled languages. But it totally makes sense from an efficiency thing for a smaller team. My take though is use the best tool for the job. Be impartial about that and you get the best tools in the stack.

Thanks for the explanation. If there was a front end framework that fits well into eclipse, maybe that's the first criteria, and then maybe consider recruiting some support for front end development outside of the Vaadin UI world.

I also didn't note the Spring Boot EOL question, which is another angle to consider.

[avgustinmm]

Hi all,
the current direction on Vaadin 8 UI is clear - discontinuation - as announced here. This was the only option since we have not found any volunteers to do that migration. That UI was part of the last 0.4.1 and then removed from the master code - meaning it won't be part of the next 0.5.0 release.
This issue still stays in case anyone volunteers to migrate. In that case, we might return this UI.
Unfortunately, this leaves the hawkBit without UI. Some developers are interested in writing a UI from scratch using web technologies, but it is still unclear if it could happen.
Was implemented a demo Simple UI with very limited functionality for just "play around" purposes but nothing more.

[truedat101]

Thanks for the update @avgustinmm . I had planned to write a thin (limited feature set) DM/OTA management server in open source for a project. I stumbled across this project in trying to do some due diligence before deciding to build anything. Since this project exists, I would like to use it, however, the lack of a UI going forward is a concern. I need a UI that is ops friendly for customers that will have to maintain devices out in deployment. I can't give anyone a backend DM system without some GUI, although yes, I guess I could give some ops people scripts. Or do the approach of something that is just slurping release artifacts out of Github.

So, if I understand correctly, #1510 and #1554 remove the Vaadin UI. I will consider then putting a UI on this with a framework that I am familiar with as a strawman concept to scope the effort. What would help, do there exist UI blueprints, a UI specification, or some other form of design documents associated with the UI as it existed in releases <= v0.41? I was impressed by the scope of the existing UI in looking through the demo. This isn't a small project. I think taking a design blueprint approach starting from a UI specification is the way to attract web designers in any case. I am assuming the authors of the current UI are still involved?

[avgustinmm]

There is no UI specification I know about. I suppose the old UI could be used as a reference though probably some aspects could have been done better in it.
Unfortunately, the authors of the legacy UI are not involved in the project anymore. This was something that made the legacy UI migration harder for us which contributed to the decision to discontinue the legacy U.

[truedat101]

Thanks @avgustinmm , I'll take a look through the online demo and see if I can roughly map out what's there in terms of scope, how many screens and complex interactions, features packed in each screen (table sorting and search are always a tricky thing to work out).

On the scale front, what is the max number of devices you guys have seen deployed under management through this system? I am thinking ahead on how a UI needs to be loaded up to test the responsiveness of the UI under those conditions.

For my own project, it won't be more than 300 devices initially but will potentially ratchet up a lot after about a year.

[truedat101]

In terms of RFEs for the UI, is there any single laundry list of UI changes or new enhancements that people have been clamoring for?