[
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.
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