[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [p2-dev] Versions that are not OSGi compliant

Hi Jeff,
I've done research on the impact on P2. A Version abstraction (the OSGi Version) is present and it is used more or less everywhere. It will of course need to be replaced by something a bit more generic and extendable but as far as I can see, doing so will have a low impact on the implementation. The generic variant must understand the Comparable interface and in addition we must also add a generalization of the VersionRange.

The I/O for the Version must be elaborated so that non-OSGi versions can serialize/deserialize themselves. In our own implementation we have chosen to do this with an extra and optional XML attribute named versionType. An alternative could be to decide on a delimiter, say '#' and store non-OSGi versions in one string using a <version>#<type> notation. I think the former is cleaner.

Basically, I think that's all it takes. Some though must be devoted to what should happen when version incompatibilities are encountered (code that manages features and bundles in Eclipse won't care much about other types of versions for instance) and how to propagate that in a nice way.

You ask for examples and usecases. The first example I can come up with is related to how many open source projects do their versioning today. Somewhat similar to OSGi but with one very significant difference. For two versions that are otherwise equal, a lack of qualifier signifies a higher version then when a qualifier is present. I.e.


The 1.0.0 is the final release. The qualifier happens to be in alphabetical order here but that's not always true.

Looking into a Redhat Fedora distribution and you will interesting versions like:

KDE Admin version 7:4.0.3-3.fc9 (leading separator is a colon)
Compat libstdc version 33-3.2.3-63 (leading separator is a dash)
Automake 1.4p6-15.fc7

The same is true for many maven repositories and things found on Sourceforge, Codehaus, etc.

P2 itself uses an OSGi incompatible version for its repository versions. The current repository definition is version "1".

Usecases then. Our objective with Buckminster is to be able to provision all kinds of things. Not just the Eclipse Runtime but also the workspace and perhaps external things needed in a build/test harness. This can include artifacts from various places using various versioning schemes. Let's say I'm a web developer. I want to install:

1. The Eclipse IDE.
2. Some web-developer extensions to the IDE.
3. JBoss Applications server.
4. PostgreSQL Database.
5. A populated workspace, complete with preferences and all code that I'll work on.

It would be extremely cool if we could model everything using IU's and use the p2 resolver/installer to do the work.

Kind Regards,
Thomas Hallgren

Jeff McAffer wrote:
Feels like an interesting requirement. Some usecases and examples would be helpful. Have you had a chance to look at what the impact of this would be on p2? On the surface you would think that we use versions all over but perhaps it is more isolated...


Thomas Hallgren wrote:
A while back I brought up the discussion about versions that are not compliant with the standard OSGi format. A brief discussion with Pascal can be viewed here:


I also entered a bugzilla


This issue important to us and as we're moving our technology closer to P2 we would really like to see a resolution. We are of course willing to contribute, partly or in full, if that's what it takes. We have good ideas of how this can be done without any impact on resolution performance. The thing missing at this point is some enthusiastic responses from the p2 team :-)

So what do you think?

Thomas Hallgren

p2-dev mailing list
p2-dev mailing list