Sunday, May 30, 2010

Managing enterprise clients with p2 query api

In my last post I left some quite angry words to the p2 team, I hope they will forgive me. After some more days of intense research I finally made p2 do what I want to. And you might want to notice that I'm quite happy about that.

Our system (It's german,  Buchmanager) is a client server architecture with hibernate/spring on the backend and a remote RCP Client. Our customers have a strong demand for automated updates, as users are forced to sync their client on server updates.

The Problem: Client and server have to match and we cannot know what server version the customer is running.

The Solution: p2 queries.
At Workbench startup the client asks the server for the required client version numbers. Then we make a p2 Query with a VersionRange (as qualifier may indicate a compatible update)

IQueryResult matches = queryable.query( QueryUtil.createIUQuery("de.eiswind.mango.client.core.mango",new VersionRange(Version.createOSGi(major, minor, micro), true, Version.createOSGi(major, minor, micro + 1), false)), new NullProgressMonitor());
Thereby we ask the repository to give us "product" IUs only matching the servers requirements. Then we use the high level api UpdateOperation to resolve an update for us. As there may be updates for a higher (=newer) server version available, we use "setSelectedUpdates" to Update only to the compatible client. this is quite easy using the equals & compareTo on Update & Version classes.

I have to note that we had to remove the p2 ui bundles completely, as they would have still offered the _wrong_ update to the user. I guess that could be changed using a Policy, but that is work to come when we feel a need for a ui.

Follow me on http://twitter.com/thomas_kratz

Tuesday, May 25, 2010

p2 is powerful, but still a nightmare to me

I started my first steps with p2 for our RCP app on eclipse 3.4, I remember I finally had some working stuff after some fights. But then came the 3.5 release and everything had changed. I found so many changes in the api that I got frustrated and throwed the whole thing away. Now that with 3.6 the API will become stable, I gave/give it another try. I found some tutorials and last but not least the examples on the p2 wiki. First to say, the examples did not work without some tweaking. I have some special requirements, as I need to make sure of the version that gets upgraded to ( The users client has to be compatible with the customers installed server version,  so I cannot update to the newest version in many cases). In general p2 seems to be made for that, and I still would prefer to have p2 over some local webstart deployment as I could push out minor fixes to my clients transparently. But on the other hand I prefer to use mainstream technology, and although so many eclipse users use p2 for a while, developers seem to find it hard to adopt it. I read many posts of people that gave up on p2, and guess I spent 5 days already on it and it still doesn't work. Its time consuming hence you can't test it in hosted mode, so its always at least a 5 to 6 minute build, sometimes evenlonger if I have to wait for my 1Mbit upstream to publish a repository change. I got help from one developer on the p2 mailing list, but my last questions remain unanswered. If you look in the p2 forum section, there are only a handful of posts and most of them are unanswered too. I guess p2 has made some progress, but documentation is still poor and looking at the traffic I see on the mailing list, I think the p2 dev team hasn't got that they have to help people adopt this othwerwise great technology in order to make it a success. I can fully understand many people wishing back for the old UpdateManager and telling you not to use p2. But if you look at it for some time you can only guess its power and I would like to see that it gets adopted by more people than now. The community has to be built and I wish I could see some more effort there.

Monday, May 17, 2010

Having a hard time with p2.data.area

I knew it won't be easy, but I guess it shouldnt be that hard to set up p2 updates for my app. I spend 2 and a half days now on it and its still not working ( apart from some issues that I hope to get help from the p2 dev team). One thing that took me hours to find was that I had set the osgi.configuration.area to the user.home directory. pde build adds then a line p2.data.area=@config/../p2 to the config.ini. That makes the platform not see the preferences generated from the p2.inf and therefore it didn't see my repositories. I really didn't see this for hours of failing.

Saturday, May 15, 2010

PDE build ate my feature

Having my way back to p2 after it should be stable now, I started off building a repository for my product, thats made up of three features. However one of the features was mising in the repository for a reason I don't know. I double checked everything and ended up moving the plugins from the missing feature to one of the features that where working. Thats no prblem as I always wnated to do that, but I wonder if anyone elde has seen this before and could tell me a reason.

Sunday, May 9, 2010

The power of messaging

I've written some posts about messaging in enterprise eclipse applications. Yesterday I made another quick hack thats really beautiful to me. In our app we have lots of ValueLists that make up the selections in the combos. These lists are customizable, so they may change. Up to now you had to restart the client to make the changes take effect as the lists were once fetched from the server at workbench startup.

Now I made a simple change, if I get an update to a list from the server, i send an invalidate message to all online clients through xmpp (did I mention we use apache vysper as xmpp host ?) the client then simple removes the list from its storage and next time its needed it will get fetched from the server with its new state.

Took me 15 minutes to implement the whole thing and now the lists in the client are always up-to-date.
Nice :) This could make up a whole client side caching mechanism if needed.

Jupyter Kernel for Java9