[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [p2-dev] Querying remote p2 repositories
- From: "Kopecz, Klaus" <klaus.kopecz@xxxxxxx>
- Date: Fri, 27 Jul 2012 16:27:50 +0200
- Accept-language: en-US, de-DE
- Acceptlanguage: en-US, de-DE
- Delivered-to: email@example.com
- Thread-index: Ac1r/0i86AaUso5xQkOHV2/+elY4LAAAbKBw
- Thread-topic: [p2-dev] Querying remote p2 repositories
I'm a little confused what the "p2 area" actually means. My assumption was that it corresponds to the "p2" folder an Eclipse installation again containing core/engine/repository folders with cached data etc. Does your comment mean that I can refer also to an empty folder when instantiating the ProvisioningAgent like IProvisioningAgent agent = agentProvider.createAgent(new URI("file:/myEmptyFolder")); ?
If this would be fine for the agent, I could create the Repository Manager and proceed ...
Interesting that you mention b3 aggregator (I'm heavily using it and praising it all the time ...). A very basic task of b3 is to read metadata from remote repositories, but I guess it's done also using a p2 agent? Or would I be able to reuse a "simpler" read API from B3?
The use case behind my question is that I'm creating .product files (product configuration files) out of (well-controlled) p2 repositories. The products are then materialized with Tycho. Unfortunately, .product files must contain a list of all installable units which makes up the product. For me the p2 repository is the main unit of granularity and whenever something changes with this p2 repo, this shall be reflected automatically within my next product build. Therefore, I'm extracting all features from a content.xml and populate the .product file before building the product.
From: p2-dev-bounces@xxxxxxxxxxx [mailto:p2-dev-bounces@xxxxxxxxxxx] On Behalf Of Henrik Lindberg
Sent: Freitag, 27. Juli 2012 15:54
To: P2 developer discussions
Subject: Re: [p2-dev] Querying remote p2 repositories
You were on the right track - what you want is a "p2 area" that is used for the purpose of answering your queries. You want that to be separate from the "p2 area" used in the application that wants the answers to those queries - or you will pollute the runtime with queried meta data (caches etc.). This way you can decide if you want to keep the cached data for the next invocation (able to answer queries faster if nothing has changed in the repositories you are querying etc).
Not sure if there is any command line "p2 query" utilities around.
One approach is to use the b3 aggregator project's EMF model of p2 repositories (it can load p2 repositories using the p2 api's, it allows manipulation of the repository and you can write it out again as a p2 repository. But guess this is just as difficult in your Maven/Tycho context as using a p2 agent and a p2 query. OTOH, the b3 aggregator is a tool for performing slicing/dicing/validation/aggregation/mirroring and reauthoring of p2 repositories - maybe what you want to do falls into this category?
Hope that helps.
On Jul 27, 2012, at 15:42, Kopecz, Klaus wrote:
I'm looking for a simple way to query a remote p2 repository (simple and/or composite). The p2-API documentation at help.eclipse.org indicates that this can be done in the context of having a ProvisioningAgent representing the "p2 area" of an Eclipse installation.
My context is different. I want to query a p2 repository in the context of a Maven/Tycho build and therefore cannot refer to any profile or "p2 area". Therefore, I'm looking for some basic p2 infrastructure which can read (or even query) the metadata of a remote repository basically by providing the URL. While I could write some stuff to read and analyze a remote content.xml file, things get more complex if I want to abstract from having simple and/or composite repositories which differ in their file layouts and decomposition into multiple metadata sources. Having something which could do this abstraction for me would be helpful.
Thanks for any suggestions ...
p2-dev mailing list