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
From: Thomas Hallgren <[EMAIL PROTECTED]>
To: Equinox development mailing list <[email protected]>
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
[email protected]
https://dev.eclipse.org/mailman/listinfo/equinox-dev
<<inline: graycol.gif>>
<<inline: ecblank.gif>>
_______________________________________________ equinox-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/equinox-dev
