Bugzilla – Full Text Bug Listing
| Summary: | [repository] Should be able to specify order or priority of artifact repositories | ||
|---|---|---|---|
| Product: | [Eclipse Project] Equinox | Reporter: | David Williams <david_williams> |
| Component: | p2 | Assignee: | P2 Inbox <equinox.p2-inbox> |
| Status: | CLOSED WONTFIX | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | P3 | CC: | beyhan.veliev, gunnar, jeffmcaffer, pascal, samuelwu |
| Version: | 3.7 | ||
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | stalebug | ||
|
Description
David Williams
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. |