RFC 112 is not a standard, but please note that and are
specifically allowed. Rewriting bindex will not fix the problem if you
want to interoperate, you have to use another filter impl to achieve
that.
Kind regards,
Peter Kriens
On 21 jan 2008, at 16:18, ChangWoo Jung wrote:
ChangWoo,
There currently is no implementation of OBR. If you look earlier in this
thread you will see talk of investigating an OBR repository adaptor for p2.
Thomas Hallgren showed interest in implementing such a repository adaptor.
Thomas, do you have any interest in doing/contributing this
With the current APIs, profile addition / deletion and update goes through
special APIs on the IProfileRegistry.
In the light of the changes on the IDirector / IPlanner API, I would be
tempted to revise the IProfileRegistry API to see if these methods still
make sense and if they are implemented
We are on the verge of changing the IDirector / IPlanner APIs to something
more extensible.
The capsule summary of this change is, the install, uninstalll and update
method will be merged into one taking a change request (name to be ).
Also the Profile class will loose its setters and insetad
I am also interested in this area. I will take a look on that too.thx
ChangWoo Jung
From:
Thomas Watson [EMAIL PROTECTED]
To:
Equinox development mailing list equinox-dev@eclipse.org
Date:
01/22/2008 10:54 PM
Subject:
Re: [equinox-dev] OBR
ChangWoo,
There currently is no implementation
Thomas Watson wrote:
There currently is no implementation of OBR. If you look earlier in
this thread you will see talk of investigating an OBR repository
adaptor for p2. Thomas Hallgren showed interest in implementing such a
repository adaptor. Thomas, do you have any interest in
I think I'd have to see the changes first, but my initial reaction is that
we probably want to get rid of IProfileRegistry.updateProfile(Profile).
I think profile registry would still have add/remove API, and API for
querying and getting the profiles. I don't see it necessary to make the
engine