Re: [equinox-dev] p2 and non OSGi components

[Thomas Hallgren <thomas@xxxxxxx>]

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.

Regards,
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.
>
> PaScaL
>
> 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>
>
> To: 	
> Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
>
> Date: 	
> 05/12/2008 11:21 AM
>
> Subject: 	
> [equinox-dev] p2 and non OSGi components
>
> ------------------------------------------------------------------------
>
>
>
> Hi,
> 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@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/equinox-dev
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> equinox-dev mailing list
> equinox-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/equinox-dev
>