Community
Participate
Working Groups
I'm opening this bug to document and track a discussion started on p2-dev list. See http://dev.eclipse.org/mhonarc/lists/p2-dev/msg03898.html Via composite repositories, a number of artifact repositories can come into play while finding "matching" artifacts. There are many circumstances where some order or priority of can be associated with at least some of the repositories. Some of them could be on high bandwidth, highly mirrored sites, for example, for all the most recent artifacts ... while some artifact repos might be on low bandwidth locations, say for rarely needed old artifacts. A problem (of unknown magnitude) occurs then the same artifact exists on multiple repositories. In that case, it'd be best to be able to give some "hints" as to which ones should be preferred. There could (possibly) be other ways of solving the main problem (which I would not know about, or how to do, at the moment) but fundamentally, at eclipse.org, we want to give priority to repositories on "download" server (since those are mirrored, should have a mirrors URL, etc.) intended to be frequently served, etc., and steer traffic away from "archive" repositories, since, by design, those are not mirrored, since they should, as a whole, be rarely needed. According to the discussion on p2-dev, there are some optimizations already built in ... such as "file:" locations are given priority over "http:" locations (but is not spec'd) and currently the artifact are searched "in order" they are listed in the compositeArtifacts.jar/xml file. So, one solution is so simply "spec" that behavior, and composite repo creators can simply control the order the repos are listed. Another, more explicit, solution might be so allow a "priority" attribute (or similar) on each repo listed. I just wanted to capture the requirement here (rather than merely "leave" on the p2-dev list).
Actually Tycho has the same requirement, but for an entirely different reason: On a developer's PC, the situation can occur that artifacts with same id and version have different content (e.g. if no time-based qualifier is used). Therefore we would like to be able to prioritize artifact repositories, in order to prefer the most recent artifact (e.g. from the current reactor) over the outdated one (e.g. from the local Maven repository).
I think the notion of which server/repo is best is more in the eye of the beholder than of the producer. p2's artifact download manager should do a decent job of picking the fastest repo/mirror available. It may periodically try a slower one but in the long run fast ones should end up being used. If that is not happening then perhaps it needs to be fixed. I'm somewhat reluctant to say that repo producers should be making assumptions about the consumer's network connections. As for comment 1, that's just crazy talk! ;-) I understand that sometimes it just happens but really don't think that it should be the normal operating procedure. A fundamental premise of p2 is that the id and version uniquely identify content.
(In reply to comment #2) > As for comment 1, that's just crazy talk! ;-) Thank goodness someone else said that. :) [and, actually, I thought Tycho had improved their support for 4 part version numbers ... but, I'm not very familiar with it, so maybe I heard what I wanted to hear.] > I think the notion of which server/repo is best is more in the eye of the > beholder than of the producer. p2's artifact download manager should do a > decent job of picking the fastest repo/mirror available. It may periodically > try a slower one but in the long run fast ones should end up being used. I partially agree, and maybe what you suggest is possible, that's why I called them "hints", but, remember, I'm talking about the "high level" composite repositories. I'm not sure how "artifact retrieval" is currently implemented, but sounds like an impossible task to optimize over the high level composite repositories plus combined with all the repositories they point to. If it finds "artifact A1" in the first place it looks (which may or, may not, in turn, offer a list of mirrors (which could be optimized over) then it seems inefficient to continue looking for other places it might be just to see if its faster (I know, I am over simplifying ... but, hopefully illustrates the difficult task of optimizing all combined artifact repositories). But ... primarily ... I opened enhancement request since on some networks (such as the one the Eclipse Foundation provides us :) there are rules or policies about what you should and should not do, about what is used for what ... and not sure it all comes down to easy to determine measurements made by clients ... so I'm not sure how else those policies can be coded or portrayed to p2. To me, composite repos seem like a potential place ... but would welcome suggestions as to where else.
I think that this issue is quite important because currently p2 doesn't have any strategy to prioritize artifact repositories like for mirrors. IMHO p2 should come with at least two strategies: 1) p2 specified/determined order of the known artifact repositories 2) user specified order of the known artifact repositories Currently, for a programmatic use of p2 a workaround for this issue could be to create a composite repository on the fly and order the artifact repositories in the desired order. May be the fix for this issue could go in this direction also.
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. If the bug is still relevant, please remove the "stalebug" whiteboard tag.
