Bugzilla – Full Text Bug Listing
| Summary: | Older features presented in category in Helios repository | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Equinox | Reporter: | Ralf Sternberg <rsternberg> | ||||||
| Component: | p2 | Assignee: | Susan McCourt <susan> | ||||||
| Status: | RESOLVED FIXED | QA Contact: | |||||||
| Severity: | normal | ||||||||
| Priority: | P3 | CC: | carm, david_williams, pascal, thomas | ||||||
| Version: | 3.6 | Flags: | pascal:
review+
|
||||||
| Target Milestone: | 3.6 RC1 | ||||||||
| Hardware: | All | ||||||||
| OS: | All | ||||||||
| Whiteboard: | |||||||||
| Attachments: |
|
||||||||
|
Description
Ralf Sternberg
Created attachment 167616 [details]
zip of the 3 content.xml currently at /releases/helios
For the convenience of anyone else who needs to look at this in detail,
here the three content.xml files involved.
Each is in a subdirectory where it is pretty obvious which goes with which milestone:
M5 201002042330
M6 201003190900
M7 201005070900
Susan, do you work on this categorized dialog? I'll assign to you to begin with, but pass it on as appropriate. Here's some observations I see, so far .. the categories involved and their versions: What is the "rule" about categories? I seem to recall a discussion long ago, that their versions only need to be different, (if their contents are different) and that "order" didn't really matter. Is that true? These are all clearly different and not in order of milestone in any way. category definitions EclipseRT Target Platform Components [category] M5 201002042330 0.0.0.7O7m5cLdPY6EBAuTekVspZk_z-PL (lowst version) M6 201003190900 0.0.0.8E7y7IcLZk_hEERHv039rxRCYZ0C (highest) M7 201005070900 0.0.0.7x855cLT3pbEFtBdvcj0pxi4uW2t (mid version) Web, XML, and Java EE Development [category] M5 201002042330 0.0.0.7h7b8acLTVU6EEx8bhNkSz0tfu6c (mid) M6 201003190900 0.0.0.7f7a_7cLTN0LEE04ZhogXwfdvAZ7 (lowest version) M7 201005070900 0.0.0.7h7c_7cLSoDVEEx8bsagiBZctEg2 (highest) For the RAP Runtime SDK case, it does come from the "hightes" version (which is not the most recent, but which is M6). [M6] Rich Ajax Platform (RAP) Runtime SDK 1.3.0.20100316-1859 [If I'm looking at it right, of course ... hard to read a megabytes xml file :) For the second category where RAP Tools resides, Web, XML, and Java EE Development, it "comes from" the "middle" version range. I checked for another feature in there (XML) and same thing, comes from the "wrong" middle category version, which happens to be the earliest milestone. [M5] Rich Ajax Platform (RAP) Tooling 1.3.0.20100201-1240 [comes from mid version category, which is not "latest") [M5] Eclipse XML Editors and Tools 3.2.0.v200906300123-7H7AFPbDxumIGI88qg2GnxTXo7ye [also from mid version category] I spot checked some others (e.g. Datatools) and it was wrong, and off hand seemed to be some different pattern. So ... what should we be looking at here, to debug this? Does it appear the content.xml files are generated incorrectly? Or is there something amiss in the UI's categorization algorithms? How is it supposed to work? (In reply to comment #2) > Susan, do you work on this categorized dialog? I'll assign to you to begin > with, but pass it on as appropriate. > > Here's some observations I see, so far .. the categories involved and their > versions: > > What is the "rule" about categories? I seem to recall a discussion long ago, > that their versions only need to be different, (if their contents are > different) and that "order" didn't really matter. Is that true? These are all > clearly different and not in order of milestone in any way. Yes, the rule was that the category versions needed to be unique, but otherwise the number does not matter. (This is needed so that queries of the category IUs treat each category as a unique IU. Prior to unique versions, category content was being lost and you'd see only the content for only of the category versions - usually the first or last encountered depending on the implementation of the query). In fact, bugs like this one appeared before we had versioned categories... On the UI side, the category name is used to "merge" categories so that repositories which contribute to the same category will have their content merged. > > So ... what should we be looking at here, to debug this? Does it appear the > content.xml files are generated incorrectly? Or is there something amiss in the > UI's categorization algorithms? How is it supposed to work? I looked at the latest and the previous files, and the categories seem correct. Something is definitely going wrong here. I observe that when I look at the Helios repository and specifically the "EclipseRT Target Platform Components" category, I'm seeing the M6 content. All the versions are from the mid-March time frame. Whereas in the later content.xml, the category is correctly referring to the later versions of IU's. Since we can see all the versions properly in the non-categorized list in the UI, we can conclude something is going wrong on the client side in assembling the categorized list. Either - something is wrong with the "category query" such that only one of the category versions is ending up in the results. - something is wrong in the CategoryElementWrapper/CategoryElement mechanism in the UI that merges same-named IU's such that we are losing information - something is wrong in the "member of category query" such that we are ignoring some of the members We had multiple passes of refactoring of queries, so it's possible that this got broken without us realizing it. Or I broke it during a UI refactoring and didn't realize. I know this broke at least once during M5/M6 when the old UI "meets any requirement query" was accidentally replaced with a "meets all requirements query." I found and fixed it then, but did not recheck since then. I can look at this in more detail tomorrow. cc'ing Thomas in case he has insight or the time to look at this before I do (time zone favors him). changing title to more generally describe the problem (that it effects many if not all features). Moving to p2. I've found the problem. What was the problem? (In reply to comment #3) > We had multiple passes of refactoring of queries, so it's possible that this > got broken without us realizing it. Or I broke it during a UI refactoring and > didn't realize. I know this broke at least once during M5/M6 when the old UI > "meets any requirement query" was accidentally replaced with a "meets all > requirements query." I found and fixed it then, but did not recheck since > then. Well, it has been broken since this time, and my fix at the time addressed only one of the symptoms. bug 295917 describes the original breakage, where we replaced the "meets any requirement query" with "meets all requirements query." I changed it back, which fixed that bug, but what I didn't catch at the time was the change from element.getRequirements to element.getIU().getRequirements The element is where the merging is done, and element.getRequirements was merging the requirements. The switch to getIU() only got the first IU encountered by the query and therefore only its members. So the bottom line is that the "member of category query" needs to be based on a collection of requirements, not one particular IU. That gives the UI the flexibility to assemble/merge requirements as needed. For now I have copied the "matchesRequirementsExpression" from QueryUtil and created a query with the merged requirements. In 3.7, we should define a new QueryUtil API that can be passed the requirements. Created attachment 167736 [details]
patch to QueryProvider
this patch ensures the merged requirements of category elements are used in the category member query.
Pascal, can you review? Marking Thomas as well. The first one that can get to it?... I have released. Tom, please still take a look. Do you have an opinion or advice on what to do with current Helios repo? I think maybe we should remove the M5 and M6 sub-repositories, just so end-users get a "clean" categorization -- for next few weeks, until Helios RC1 released? Is there any merit to continue to leave them all there, given this bug? Maybe related, it sounds like this has been "wrong" for a while. In M6 platform also? I wonder how/why no one noticed? (There would have been 2 sub-repositories there). Probably not related ... does the 3.5.2 platform work correctly with respect to these categories? Just curious if there's any current guess if people will be able to update a 3.5x install to a 3.6x install? (I know its not promoted, or encouraged ... but its been suggested maybe that use case should be tested ... and I wonder if there's an update on that advice? Thanks, From the looks of it, the memberOfCategoryQuery is never used unless the element is a CategoryElement. So the
else {
memberOfCategoryQuery = QueryUtil.createIUCategoryMemberQuery(((IIUElement) element).getIU());
}
could be replaced with:
else {
memberOfCategoryQuery = null;
}
I'm not sure if that was intended.
> I think maybe we should remove the M5 and M6 sub-repositories, just so > end-users get a "clean" categorization -- for next few weeks, until Helios RC1 > released? Is there any merit to continue to leave them all there, given this > bug? What do we get from removing these older milestones? Do we still have M3 and M4? > Probably not related ... does the 3.5.2 platform work correctly with respect to > these categories? Yes, this problem got introduced as part of the 3.6 changes. > Just curious if there's any current guess if people will be > able to update a 3.5x install to a 3.6x install? (I know its not promoted, or > encouraged ... but its been suggested maybe that use case should be tested ... > and I wonder if there's an update on that advice? At this point the SDK supports updating from 3.5 to 3.6 (at least on my platform). To perform a train update, it takes the buy-in from everybody aboard the train. I think we can try and let users do it as their own risk but not have it be the recommended path. I'm happy to see this being discussed on the cross-project-dev ML (In reply to comment #11) > Do you have an opinion or advice on what to do with current Helios repo? > > I think maybe we should remove the M5 and M6 sub-repositories, just so > end-users get a "clean" categorization -- for next few weeks, until Helios RC1 > released? Is there any merit to continue to leave them all there, given this > bug? It depends what the merit was of leaving them there before this bug... ;-) Were you trying to test something surrounding having all the versions available? If there were some reason you needed to keep the previous milestones around (for resolving, etc.), you could still surgically correct this problem by punting the old categories from the older repos but keeping the IU's. > > Maybe related, it sounds like this has been "wrong" for a while. In M6 platform > also? I wonder how/why no one noticed? (There would have been 2 > sub-repositories there). The nature of the bug is that whether an older version of the category member was picked depended on which category IU happened to be found first in the query. So if the later category IU was found first, things "appeared" to be okay. The chances of it being wrong would increase as you had more sub-repositories contributing the same category IU. (In reply to comment #13) > > I think maybe we should remove the M5 and M6 sub-repositories, just so > > end-users get a "clean" categorization -- for next few weeks, until Helios RC1 > > released? Is there any merit to continue to leave them all there, given this > > bug? > What do we get from removing these older milestones? Do we still have M3 and > M4? > No, no M3 or M4. (They had other problems, that caused us to remove them at M5). The thing we 'get' is better testing of M7. I'm concerned the general eclipse-end-user on the street might try M7, end up selecting some M5 or M6 version of something and, at best, not testing the latest stuff. If someone speaks up the need them restored, we can. Perhaps at RC1, I'll restore M6 along with M7 and RC1 to have multiple category versions. (There were other problems with M5 categories, some thing categorized incorrectly ... and as far as I know no need to test that ... and would be better to present a representative view). Thanks for your comments, and help. (In reply to comment #15) > (There were other problems > with M5 categories, some thing categorized incorrectly ... and as far as I know > no need to test that ... and would be better to present a representative view). That may also explain why we didn't notice this bug before now. If categories were changing from M5 to M6, then no conflicts (or less conflicts) even possible. With categories stabilizing for M7, it got easier to find this... Well ... there was just one :) one new one added, and a few features moved from an old one (testing/profiling) to the new one. ... but, that did look confusing. verified on win7, Build id: I20100516-0800. (However, note that the M5 and M6 content were removed from the repo, so the old versions aren't there anymore). I scanned the uncategorized list of features looking for multiple versions, and I found some, but none that were also categorized... *** Bug 313919 has been marked as a duplicate of this bug. *** I'm afraid there's still a problem: Currently, I see the following in the install dialog using the releases/helios repo, filtering for "rich ajax": * with "Group by category" unchecked: RAP runtime of 20100518 RAP tooling of 20100518 * with "Group by category" checked: RAP runtime of 20100518 RAP tooling of 20100504 <-- !!! (In reply to comment #20) > I'm afraid there's still a problem: > Currently, I see the following in the install dialog using the releases/helios > repo, filtering for "rich ajax": > * with "Group by category" unchecked: > RAP runtime of 20100518 > RAP tooling of 20100518 > * with "Group by category" checked: > RAP runtime of 20100518 > RAP tooling of 20100504 <-- !!! What build are you using? I don't see the problem. I just tried this with Build id: I20100523-0800, Win7. I select Helios - http://download.eclipse.org/releases/helios in the install wizard and type "rich ajax" in the filter box. In the uncategorized view, I see these items: EMF RAP - Eclipse Modeling Framework Runtime for the Rich Ajax Platform 2.6.0.v20100517-1331 EMF RAP - Eclipse Modeling Framework SDK for the Rich Ajax Platform 2.6.0.v20100517-1331 Rich Ajax Platform (RAP) Runtime SDK 1.3.0.20100518-1222 Rich Ajax Platform (RAP) Tooling 1.3.0.20100518-1248 Source for EMF RAP - Eclipse Modeling Framework Runtime for the Rich Ajax Platform 2.6.0.v20100517-1331 In the categorized view, I see these items: EclipseRT Target Platform Components EMF RAP - Eclipse Modeling Framework SDK for the Rich Ajax Platform 2.6.0.v20100517-1331 Rich Ajax Platform (RAP) Runtime SDK 1.3.0.20100518-1222 Web, XML, and Java EE Development Rich Ajax Platform (RAP) Tooling 1.3.0.20100518-1248 if your build is recent, another possibility is that you have a stale repo cache? You could open the available sites preference page, select the helios repo, and press the "Reload" button to ensure that you are reading the latest site content. I'm sorry, it was my fault. I mixed up my installations and mistakenly used an M7 build. With RC2, it's all right. Please forgive the disturbance! |