[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [equinox-dev] p2 and non OSGi components

Hi Pascal,
We are thinking about using p2 as the foundation for a lot of things that we are about to build in the future the version type issue is blocking us right now.

It seems to me that approach #2 will require prior knowledge of the version types too. You cannot canonicalize a version of a certain type if you don't know how it's constituted. The whole point of recognizing the versions is to be able to put some semantics to them so that versions of a certain type can be compared with each other and ordered. Trying to squeeze them in to something understood by OSGi versioning will not cover all cases and comparing versions that origins from different types makes no sense at all.

In Buckminster, and on Cloudsmith where we have the repo in a DB, we selected approach #1 and while it's true that we cannot anticipate all version types in the world, we already do a fairly good job of understanding a majority of them and it's very easy to add a new type should something pop up that we don't recognize. The same is true for component types (i.e. osgi.bundle, feature.group, etc.)

Is there any chance that you would reconsider the approach chosen and add support for pluggable version types? We would of course offer our help with the implementation.

Thomas Hallgren

Pascal Rapicault wrote:

There is basically two solutions to this problem: 1) have pluggable version numbers 2) deal with canonicalized version numbers.

The first requires to have the provisioning system to know about all the version types possibility found in a repo ahead of time, or being able to download additional version handlers on the fly. This also then makes it harder to optimize repo queries when the repo could be stored in a DB.

The second requires at metadata generation time some understanding of the version being read to canonicalize it, thus limiting the impacted places in the system and also allowing for more optimization later.

In p2 we picked the second approach.


Inactive hide details for Thomas Hallgren ---05/12/2008 11:21:20 AM---Hi,Thomas Hallgren ---05/12/2008 11:21:20 AM---Hi,

From: Thomas Hallgren <thomas@xxxxxxx>

Equinox development mailing list <equinox-dev@xxxxxxxxxxx>

05/12/2008 11:21 AM

[equinox-dev] p2 and non OSGi components


I'm curious how p2 handles components that are not OSGi and uses version
semantics hat differs from OSGi versions. Do you have any concept of
"version types" or how to resolve queries that designates ranges of
non-OSGi versions?

Kind regards,
Thomas Hallgren

equinox-dev mailing list


equinox-dev mailing list