[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[p2-dev] Re: trouble with metadata repositories.
- From: Fredrik Alströmer <roe@xxxxxxx>
- Date: Mon, 23 Feb 2009 12:43:54 +0100
- Delivered-to: email@example.com
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; b=Y3bLXoD6VXT0x/Ti14YbxQ+Hd4gYhS2PcHYOfoEGVQ8mPbFFOnmTXJ7PkLLjF5qZrI lgmH4am7FYUHn0sUdaADt/6juBHCDHXFyUvWBRwH+keZuZ1bdTwe5BZ8Fj9VwpOoWrzL BPWlVYMUsprhFOC5k0EKV2vPxBTyCt2j3Kh+0=
For interested parties, I found the problem.
P2 caches the repository content metadata, which takes precedence over
the actual repositories when looking for provided capabilites. When I
changed the metadata repository, the UI reflected this change (showing
both required and provided capabilites), and the IU I tried to install
(which apparently was taken from the real repository) took precedence
over the cached one (I haven't been able to figure out how this
happened yet). This caused the possibilites.query() in
Slicer.java:expandRequirement() to return an empty collector,
resulting in the failure. I tried updating the p2.timestamp property,
but this didn't cause it to refresh the cache, and I eventually
cleared the cache folder to get it running.
The questions now, if anyone would like to take a crack at it, are 1)
why did the cached repository take precedence, but only when looking
for provided capabilities? 2) why is the execution path if
(validMatches == 0) (in expandRequirement()) just a warning, which
will cause it to be overshadowed (indeed, not even displayed by the
agent) by the error from the SAT-solver? And 3) how do I force it to
update the cached metadata?
On Thu, Feb 19, 2009 at 17:27, Fredrik Alströmer <roe@xxxxxxx> wrote:
> I've been playing around with a little bit the p2 agent rcp and a
> couple of repositories that the generator app has created and
> everything appears to be working splendidly. However, I wanted to try
> out the provide/require mechanism a little bit so I added a
> <provided namespace='hello' name='world' version='1.0.0'/>
> to one of the IUs, and a corresponding
> <required namespace='hello' name='world' range='0.0.0'/>
> to another. And I can't seem to figure out how to get this to resolve
> correctly; when I try to install the second IU alone, it complains
> saying that the requriedCapability hello/world/0.0.0 can't be
> satisfied, however, if I try to install both simultaneously (or the
> first prior to the second), it, again, works like a charm... How can I
> cause the second IU to be an install-root for the first one? It works
> with the generated stuff (java.package dependencies), so what am I
> missing? Or is that stuff being handled somehow specially?