[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [p2-dev] Versions that are not OSGi compliant
|
Hi Jeff,
I've done research on the impact on P2. A Version abstraction (the OSGi
Version) is present and it is used more or less everywhere. It will of
course need to be replaced by something a bit more generic and
extendable but as far as I can see, doing so will have a low impact on
the implementation. The generic variant must understand the Comparable
interface and in addition we must also add a generalization of the
VersionRange.
The I/O for the Version must be elaborated so that non-OSGi versions can
serialize/deserialize themselves. In our own implementation we have
chosen to do this with an extra and optional XML attribute named
versionType. An alternative could be to decide on a delimiter, say '#'
and store non-OSGi versions in one string using a <version>#<type>
notation. I think the former is cleaner.
Basically, I think that's all it takes. Some though must be devoted to
what should happen when version incompatibilities are encountered (code
that manages features and bundles in Eclipse won't care much about other
types of versions for instance) and how to propagate that in a nice way.
You ask for examples and usecases. The first example I can come up with
is related to how many open source projects do their versioning today.
Somewhat similar to OSGi but with one very significant difference. For
two versions that are otherwise equal, a lack of qualifier signifies a
higher version then when a qualifier is present. I.e.
1.0.0.alpha
1.0.0.beta
1.0.0.rc1
1.0.0
The 1.0.0 is the final release. The qualifier happens to be in
alphabetical order here but that's not always true.
Looking into a Redhat Fedora distribution and you will interesting
versions like:
KDE Admin version 7:4.0.3-3.fc9 (leading separator is a colon)
Compat libstdc version 33-3.2.3-63 (leading separator is a dash)
Automake 1.4p6-15.fc7
The same is true for many maven repositories and things found on
Sourceforge, Codehaus, etc.
P2 itself uses an OSGi incompatible version for its repository versions.
The current repository definition is version "1".
Usecases then. Our objective with Buckminster is to be able to provision
all kinds of things. Not just the Eclipse Runtime but also the workspace
and perhaps external things needed in a build/test harness. This can
include artifacts from various places using various versioning schemes.
Let's say I'm a web developer. I want to install:
1. The Eclipse IDE.
2. Some web-developer extensions to the IDE.
3. JBoss Applications server.
4. PostgreSQL Database.
5. A populated workspace, complete with preferences and all code that
I'll work on.
It would be extremely cool if we could model everything using IU's and
use the p2 resolver/installer to do the work.
Kind Regards,
Thomas Hallgren
Jeff McAffer wrote:
Feels like an interesting requirement. Some usecases and examples
would be helpful. Have you had a chance to look at what the impact of
this would be on p2? On the surface you would think that we use
versions all over but perhaps it is more isolated...
Jeff
Thomas Hallgren wrote:
Hi,
A while back I brought up the discussion about versions that are not
compliant with the standard OSGi format. A brief discussion with
Pascal can be viewed here:
http://dev.eclipse.org/mhonarc/lists/equinox-dev/msg04260.html
I also entered a bugzilla
https://bugs.eclipse.org/bugs/show_bug.cgi?id=233699
This issue important to us and as we're moving our technology closer
to P2 we would really like to see a resolution. We are of course
willing to contribute, partly or in full, if that's what it takes. We
have good ideas of how this can be done without any impact on
resolution performance. The thing missing at this point is some
enthusiastic responses from the p2 team :-)
So what do you think?
Regards,
Thomas Hallgren
_______________________________________________
p2-dev mailing list
p2-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/p2-dev
_______________________________________________
p2-dev mailing list
p2-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/p2-dev
