Monday, September 12, 2011

More on p2 and OBR

When I set out to write my previous blog post about why not OBR, the intent was to give, with a catchy title, an historical perspective on p2 (thus the recent title update) but also to answer people who have been asking for years this question

(and yesterday night another one of those came in).

The point was not to do a comparison of p2 and OBR as they are today, and especially not to claim that OBR is not good today. Both technologies have pros and cons. My statements about OBR were a reflection of the situation as it was ~5 years ago. To be honest, I have not been following the recent development on the spec, just heard some rumours.

When I wrote the previous post, I also wrote two additional paragraphs that I had not published. One was about our absence of involvement in the spec process and one about going forward. So here they are:

Could we have collaborated on the spec and implementation?

Maybe, but at the time the interest around OBR was rather low at the OSGi alliance, we did not had the bandwidth to drive improvements to the specification since we were focusing on shipping running software (the first release may not have been the best thing, I agree), and my management at the time was not up for the work, distraction, and frustration it could have represented. It needs to be remembered that some of us had been involved in the OSGi spec process to drive changes (adding fragments, bsn, require bundle, etc. Yes all these mostly were driven by the equinox team) and it had been a painful experience that left the people involved with scars, and made some of them the ongoing target of criticisms because of the changes they pushed for.

A couple years later (~2009?), OBR got brought back the forefront in the context of the OSGi Enterprise Expert Group. At this point, I have been involved in the spec work even to a point where I was the lead. Because of my lack of time, and the problems scoping the work, my contributions have been limited and then I stopped being involved as Sonatype withdrew from the OSGi alliance.

Is there a way forward?

Until a publicly visible draft of OBR is available, I can't provide a definitive answer. However implementing OBR on top of p2 has definitely been discussed several times and is not out of question especially if the specification stays focused on providing a resolver API and a repository API.

Now time, energy and contribution will tell...

PS: there are things that need to be corrected from Neil's post, but my other commitments are calling so it will have to wait.


Anonymous said...

p2 and ORB the fight that keeps giving and giving. Priceless..... Who knows how many years later none of the two has a viable UI to help developers and both depends on scripts and black magic to work.

davidb said...

Hi Pascal,

I think that many of the concerns you mentioned in the previous posting have been covered in the latest OBR RFC while some others, like Features and start ordering are described under a separate RFC called 'Subsystems'. Together they should pretty much address everything that you mentioned as gaps in the old OBR (which wasn't a OSGi spec BTW).

There is an EA draft available from last May that contains the OBR and Subsystems RFCs (here) but there will be an updated RFC available soon.

I would be very much interested in your opinion on the latest draft (I'll let you know when it's available).

Best regards,


Kaloyan Raev said...

p2 does a good job as Install Manager for Eclipse and a as source for target platforms for Eclipse Plug-in Development.

But when it comes to classic OSGi Bundle development, the central OBR repositories have great potential. It would be just great if bundles from OBR repos can be installed in a PDE target platform.

Pascal, do you think this could be possible with p2 in future? To read OBR repos and install bundles from there?