[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [equinox-dev] p2 and non OSGi components
|
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
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
![GIF image](gifXfbvBzF6oY.gif)
![GIF image](gifEYbKUMhgoX.gif)