Community
Participate
Working Groups
Some features still refer to the Europa update site and depending on how the feature is installed this causes p2 to go and get the content from there. Unfortunately this requires all the features to be downloaded and causes some pretty large delay for the user. In order to avoid this I think it is necessary to generate p2 metadata for europa. Note that we are also doing this for the old eclipse update site (update.eclipse.org/eclipse). David, could you please take care of this?
I'd like to understand this a bit better including who's requiring it (which features you speak of) and the urgency. Given issues as those in bug 231453 (where not all features are installed) I doubt it is the correct behavior to "suddenly" assume the P2 model on the Europa site. I doubt the same stuff would be installed, and it's impossible to tell in hindsight what's desired or intended. So ... no good to change at this point. Please explain if I have misunderstood and draw me a picture of the use case. Thanks,
What happens is that some features still refer to the Europa site. Depending on how they are being installed their installation will cause the europa update site to be added (and enabled) to the list of known repositories. As such the user experience turns out *really* bad because the digest.zip is not valid and we end up downloading all the features. So the point of generating the metadata is absolutely not to allow people for installation using p2, but simply to make sure that the user experience does not get ruined by a very large update site that nobody cares about (see also my message on the cross-project ML today). Consequently I would really appreciate if you could do it. If you don't have the time, maybe Nick could help.
Can you give an example of what feature still refers to Europa? I don't understand how having the P2 metadata would help, _without_ risking something being installed incorrectly.
Let me be a little clearer, on my concerns. In addition, that is, to my concern that P2 doesn't install the "old" update manager oriented features correctly, there's a few more. First, this particular bugzilla entry does not belong to "P2". Since it could impact Europa projects (and maintenance) then wouldn't cross-project be better? I think that'd get the proper visibility, and I'd expect some of those project leads to weigh in. Second, this is surely a work-around for a core P2 problem. We can not go back to every update site in the world, for all time, and make sure they have P2 data. So ... what needs to be changed about P2 to handle this problem correctly for this hypothetical "whole world, for all time" issue. Is there another bug open for it that I just haven't seen. This bug should reference it. I realize you are just trying to improve some one concrete situation, (which I still don't understand) but it's these high level issues that concern me (in addition to the known issue that P2 won't install old update manager features as expected). So, I'd like to understand the concrete use-case for which there are problems, have this bug moved to cross-project and have at least a couple of other Europa participants to say they would like to see this change and feel perfectly comfortable with it, and lastly, a reference to the bug that will address, long term, the issue that not all update sites will have P2 metadata associated with them. Thanks for the extra effort I'm asking for ... I'm just trying to be careful with this "group property" of the Europa update site. (As well as only fix things which I can see are a problem).
Not sure I understand the risk here. --- Case 1: If you point Eclipse 3.4 w/ p2 enabled at the current Europa site, it will do a crazy-slow install, downloading everything first to check its contents, then presenting the generated metadata to the user. Workable, but painful. If you point Eclipse 3.4 w/ p2 enabled at a p2-metadata-enabled Europa site, it will use that metadata to make the install experience much faster. Case 2: If you point Eclipse 3.3 at the current Europa site, it will do what Update Manager does currently. If you point Eclipse 3.3 at the a p2-metadata-enabled Europa site, it will do what Update Manager does currently (since it has no idea what to do with the p2 metadata, it will just ignore it). --- So, I don't see any risk here, only reward. That said, why would anyone point Eclipse 3.4 at the Europa update site? Perhaps the omission of metadata would be enough to encourage people to use the new Ganymede site instead, since there's such a huge performance improvement. What projects were foolhearty enough to use the Europa site instead of their own for their features' update URLs? (Or are we talking about products?) And why is the digest for the Europa site not valid? Couldn't that just be regenerated and fixed? (Did it get generated after each update?)
(In reply to comment #5) > > If you point Eclipse 3.4 w/ p2 enabled at a p2-metadata-enabled Europa site, it > will use that metadata to make the install experience much faster. > This is the case where things won't be installed as expected. There will be less installed than classic UM would install, in some cases (see bug 231453). You raise some other good questions (who and why, etc.). Since Europa is a production site, potentially used by some products, etc., I just think some extra care/understanding/review is warranted. Especially since providing meta data there feels a bit like a hack to get around a more fundamental problem.
> Especially since providing meta data there feels a bit like a hack to get > around a more fundamental problem. The fundamental problem is that p2 requires more fine-grained metadata than is available in feature.xml files, so that it can do the correct dependency analysis that UM was never able to do (package-level imports/export dependencies, for example). If it contacts a site that does not have this metadata, it will generate it on the fly. This is not too bad for a small site, but is very expensive for a huge site like Europa (5-10 minutes or more on a slower connection). Generating this metadata in advance simply avoids having to generate the data on the fly for each user. It's the same metadata generation in both cases, so it has no effect on the install experience other than speed. As to the question of whether Europa is relevant for 3.4 users, I know for certain there are features in Ganymede that reference the europa site. You can confirm this by downloading http://download.eclipse.org/releases/ganymede/content.jar, and looking at the repository references in the content.xml. You will see these entries: <repository url='http://download.eclipse.org/releases/europa' type='1' options='0'/> <repository url='http://download.eclipse.org/releases/europa' type='0' options='0'/> These repository references are pulled from the feature.xml at metadata generation time. If you grep over the features in the Ganymede site you'd likely find the culprit that is pulling in this reference. Perhaps these Ganymede features are mistakenly referring to Europa and they should be fixed. But, you're certainly right on two points. This is a cross-project issue, not a p2 issue. I will move the bug to cross-project-issues. You are also right that we should be cautious about doing this because it is a heavily used site. I would suggest generating metadata on a copy of the europa site, and then do some tests installing against the original versus the generated copy. This will allow confirmation of the speed gain, and verification that it doesn't affect install behaviour.
(In reply to comment #7) > Perhaps these > Ganymede features are mistakenly referring to Europa and they should be fixed. Yes, no feature should refer to update site as Europa OR Ganymede. I've opened bug 236640 to track that specific issue. Just wondering ... do "discovery sites" (as opposed to mere "update sites") result in a same/similar <repository element? Guess we haven't been too explicit about "discovery sites", but suspect Ganymede should not be one of them. Well, with the one exception of the Platform, of course ... you're special. :)
Re comment #8. I clarified this in bug 236640 before I saw this comment. Yes, they both result in repository references. Originally the difference was that "update url" references were enabled by default, and discovery url references were disabled by default. However, this turned out to be a performance problem because so many enabled repositories were being enabled by default (and a bit confusing for the user too when this flood of repositories appeared in the avaiable software tab). So, they now both produce disabled repository references (this is the options='0' part).
Here's the set of features that are referencing the europa update site: org.eclipse.stp.servicecreation_0.8.0.200805281408-07c-7I99m9XImDS9h org.eclipse.stp.servicecreation_0.8.0.200806041933 org.eclipse.stp.soas.feature_0.8.0.200805281408-07k-7MAAwAeMwGYAq org.eclipse.stp.soas.feature_0.8.0.200806041933 org.eclipse.stp.soas.runtime.feature_0.8.0.200805281408-07M-7A55S5JAS8G5P org.eclipse.stp.soas.runtime.feature_0.8.0.200806041933 These most likely should be referring to the ganymede site instead. With that said, I still think it's worthwhile to p2-ize the europa update site.
(In reply to comment #10) > org.eclipse.stp.servicecreation_0.8.0.200805281408-07c-7I99m9XImDS9h > org.eclipse.stp.servicecreation_0.8.0.200806041933 > org.eclipse.stp.soas.feature_0.8.0.200805281408-07k-7MAAwAeMwGYAq > org.eclipse.stp.soas.feature_0.8.0.200806041933 > org.eclipse.stp.soas.runtime.feature_0.8.0.200805281408-07M-7A55S5JAS8G5P > org.eclipse.stp.soas.runtime.feature_0.8.0.200806041933 I've removed these bad references from the features, so next build should eliminate the issue.
As an end user, you have no way to know if some random update site is going to refer to the Europa update site. So while the Eclipse teams can collaborate and fix all the references in the Eclipse projects, it just takes one sloppy update site out in the wild to cause the coffee-break-length delay. Our (the Pulse team's) experience is that there are enough of these update sites out there to warrant this optimization. That being said, Pulse employs a value-add optimization near this exact issue so Pulse would not benefit dramatically from such an optimization. Seems like a low risk/high reward optimization to me.
*** Bug 243178 has been marked as a duplicate of this bug. ***
Is this issue old enough and burned-out enough to close as "won't fix"? If someone thinks there is still some action that someone should take, please re-open and clarify.
