P2 deployment in enterprise applications

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.

UI programming - state of the universe

I'm currently doing some investigations on state of the art ui development. In my own project I choose RCP for many reasons. I cross posted this on the eclipse.platform newsgroup.

The general state of the universe seems to me like we are still experimenting in many areas. I've been so happy with the arrival of databinding, but it still needs a lot of coding.

I stumbled across gooey
https://aptframework.dev.java.net/gooey/gooeyController.html


they have some interesting ideas. For e.g.

automtic binding by convention (perhaps overidden by annotations)

they suggest to have some mechanisms like

@Event void ok() {
to implement a listener for a button thats named okButton.

and some other nice ideas. Wether this plain java approach is a good idea or if there are better ways - I will leave that to be discussed.

I'm not solving the puzzle (at least not by now :) but I agree with many voices that coding ui's by current api's is sometimes comlicated and ugly.

I can see two approaches:
Markup (Xaml?) and DSLs (JavaFX, glimmer etc)

the problem I see with markup is that its great for building tools around, but it's getting bad when you need bridges to code (With Microsoft blend beeing nice, a so called UI Designer still has to know method names and blend doesnt help him thereby afaics) XUL has been araound a while but I don't know anyone who uses it.

The web guys come up with EL there and once again you have some kind of code in your view definition. I would prefer to see a button, and the magic behind the button (its behaviour) should be defined in a controller. Even if you disagree and allow some code in the view definition, it still hard to validate and refactor. The problem with markup is, that its hard to reference from code, and even if you do that (by id conventions, by xpath or something else) it strikes you when you want to refactor somehing.

I tend to like the dsl approach more, as it can be compiled, maybe it can be typesafe and have tight java integration. And it would be even better if we had cross language refactoring tools. the glimmer approach implies groovy, and maybe I didnt understand it right, but I think its still some effort to cleanly use groovy objects from java.

All in all i would like to see a clean separation of the visual definition and actual behaviour that should be in code anyway.

One nice idea I saw from the .NET guys is the concept of a visual state manager.
http://timheuer.com/blog/archive/2008/06/04/silverlight-introduces-visual-state-manager-vsm.aspx

I think I like the idea. Coding state changes and their dependencies is sometimes not trivial and mostly always hard to understand when you look at the code only. So the idea of having

visual declarative elements (be it markup os dsl)
style information for the elements (oh no, not css)
different defined states of the declared elements
binding of elements to domain models
actual behaviour (aka the controller)

as separate concepts has some appeal to me.

If we could cleanly reference visual elements in a straightforward way some things will get easier (think you declared a button in the visual layer, how is it referenced in the controller?) a typical mess we have today is when it comes to ui test automation. Look at the SWTBot approach, coding names for the elements to make them testable. Thats 2008, I guess (sorry for beeing sarcastic, I have hard times with my UI tests)

I think we still have lots of room for improvement. I'm just trying to get some pieces together. I would be glad if you let me know what you think.