So many times I asked people I met, why they have choosen a browser based solution for their business applications that are never meant to appear on the internet. And, as was to be expected, most of the time I didn't hear many meaningful arguments. One of the arguments that people tell in almost any cases is "no trouble with deployment".
I remember trying different strategies for rich client apps deployment. Some years ago we used webstart with a Windows shortcut, which sometimes made some trouble (I never made it deeper into it) when it didn't get the changes and started from its cache instead of downloading the updates.
In a client server environment it's critical that clients are synced when service api breaking changes are made on the server side. So after many years I came back to the problem with my project Mango (its about publishing business btw.) which is implemented on Eclipse RCP for the sake that I believe its the best platform we have in java-land. For sometime (as with many projects) we had only a single production installation and I didn't put much effort in installation issues. I told the admins what was to do to get it running.
But times changing and installation count is rising, I noticed that I had to improve things around deployment. Typical update scenarios that eclipse mechanisms adress don't match truly what we need, because we can't update from a central point since client and server updates must be synced. As for now I decided against an automated server update (which I may rethink...).
But with some effort (had to do some minor but hard to find tweaks on the current p2 implementation) we now install the p2 repository for our client on an embedded webserver in our server installation. With again some tweaking I made the p2 installer app webstartable and you guess, it too comes with the server installation.
Now its a single selfextracing jar, that updates the server platform, and runs all needed changes (database schema changes, sometimes data needs to be converted etc). For a single turn users need to be emailed the link to the installer jnlp to get the current client installed on their boxes. From now on (it cost me some days, my wife can tell it was tricky...) whenever one of our users decides to update his installation to the current release, its a simple one liner to update the whole scenario.
As I ran out of time its a little q&d trick on the client, as it simply starts up with a null perspective and disabled menus when server api has changed. It then updates itself from the p2 repository and needs to be restarted.
Things that still need to be done is notifing running clients when the server goes down for maintenance, but that could gives us room for new ideas in any way.
So to say, what I guess I will hear now is, that in big client installation count this will still need high network traffic when on monday mornings people fire up their clients and all request an update at nearly the same time. But without having scientific proof I guess that with p2 we can update to the point what needs to be updated. So actual download size (in our case, the client code is actually quite small compared to the base platform plugins it depends on) won't be more than some megs.
So next time I stumble across the above arguments, I think I'll have something up the sleeve.
Today I finished my migration of a (small) demo app to the new Vaadin 8 API. First of all: Vaadin 8 has a compatibility layer. Everything ...
In this tutorial we will put together a full application stack for a multi-tenant architecture. We will be using Vaadin and Vaadin-Sprin...
Vaadin 8 (currently in beta) comes with a whole new DataBinding API that makes heavy use of the Java 8 Lambda Features. Unfortunately Java...