Community
Participate
Working Groups
currently the ProvisioningContext API is asymetrical. You can get its repos as I*Repository but can only set them as URIs. While that in and of itself is not tragic, several cases have come up recently where I have a set of real repo objects to use for provisioning but they cannot be used directly. In some cases they are spoof up composite repos for example. Proposal: - add set*Repositories(I*Repository[]) or better yet use Lists in the args. More generally these repos are generally just going to be queried so why not just allow IQueryables to be supplied?
+1. And to make things more confusing, some (provisional) API (namely in the publisher) uses 'real' repos. Working against the p2 API, I find myself constantly switching back and forth between I*Repository, and the URI.
There is a drawback in that if people are managing their own repos, then p2 cannot manage them. So it may be harder to flush and reload for example.
IIRC this asymmetry is desired but I don't recall the reason. I think this has to do with reference following. CC'ing Susan in case she does remember. Found below a few bugs where we discussed the addition of reference following: https://bugs.eclipse.org/bugs/show_bug.cgi?id=311393 https://bugs.eclipse.org/bugs/show_bug.cgi?id=305226 https://bugs.eclipse.org/bugs/show_bug.cgi?id=310206
(In reply to comment #3) > IIRC this asymmetry is desired but I don't recall the reason. I think this has > to do with reference following. CC'ing Susan in case she does remember. The original API trafficked in URI's completely (setter and getter). We were trying to solve two problems in 3.6: 1) The problem with the URI getters was that we had specialized code (mostly in the planner) that was iterating these URIs and loading repos. We realized that we were mimicking the operation of the repo managers, and it would be cleaner to traffic only in queryables, so that clients of the API could get the desired queryable and then treat them as they would a repository manager (iterating repos) or a repository (iterating IUs, or artifacts). 2) We wanted to be able to follow repository references when trying to resolve an install (the bugs Pascal mentions above). This means that repositories in addition to the ones you specify may get loaded. So we didn't really consciously decide that the asymmetry was needed, or a good thing, but I think the main issue at this point is that the current API enforces that the repo must be known by the manager, whereas the passing in any random instance of a repo doesn't make clear what the relationship is. I think the most typical way to speak of repos is by URI (look at the repository manager API) and that publisher is kind of an aberration because it is tooling that creates repos. I'm not in favor of introducing new API that passes in repository instances, but on the other hand, generalizing the API somehow to deal with queryables seems like a decent idea. In the same way we use #setExtraInstallableUnits maybe we could just support extra queryables that should be consulted, and then one could use random sets of IU's, or hand-crafted repos, etc.
I fully support the generalization to IQueryables. The repo manager is a useful tool for managing repos but should not IMHO be the only way of getting repos.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
I'll assume this issue has died.
