Community
Participate
Working Groups
Created attachment 137479 [details] Screenshots Tested with 3.5RC2: Consider two update sites that look like this: * Site 1 ** Category FOO *** Feature a *** Feature b ** Category X *** Feature c * Site 2 ** Category FOO *** Feature d *** Feature e ** Category Y *** Feature f Using the "Install New Software..." UI and selecting one individual site, you see the structure as outlined above. Selecting "--All Available Sites--", however, shows the following: ** Category FOO *** Feature a *** Feature b ** Category X *** Feature c ** Category Y *** Feature f Category FOO should show four features instead of two. Find attached a ZIP file with three screenshots showing the problem. I can also attach artifact and content XMLs if it helps.
Attaching the content.xml of each site would really help (or create a simpler example)
Created attachment 137488 [details] jarred content.xml of first site No problem :-) Here's the first site.
Created attachment 137489 [details] jarred content.xml of second site ...and here's the second site
This sounds like the categories might have been generated before bug 261104 was fixed. This would cause the same-named categories to be treated as equals in the query, so we wouldn't properly merge them. Ian, can you take a look at the metadata? I haven't looked (yet), but I suspect this metadata could have been generated before we solved that problem?
The categories don't have unique versions, they just have 0.0.0. So yes, this is a duplicate of bug 261104. Achim, if you use a recent version of p2 to generate your metadata this problem should go away.
I'll mark this as a duplicate of 261104. Achim, please reopen if you still see a problem after regenerating metadata. *** This bug has been marked as a duplicate of bug 261104 ***
I'm using Buckminster to generate the site. So I guess I'll just wait until the Buckminster folks pick up the new p2 version and I'll be fine. Thanks for the quick replies!
The categories are using the same id although they reside in different repositories. Is that really allowed? What happens if the categories are versioned? I thought it was like this: 1. If they have the same version, they are considered to be the same IU and therefore only one is used. Which one is probably dependent on how the repositories are queried. 2. If they have different versions, only the latest version will be displayed. 3. If they have different id but the same name, both will be used and they will be aggregated in the UI. Or have I misunderstood?
That makes sense to me. I'll try regenerating the sites with different IDs (but same name) first thing tomorrow morning.
different ids/same name should work. However, we expected same ids/different versions to also work. The publisher (post-bug 261104) will generate a version based on timestamp, and this will ensure the IU's are viewed as "not equal" at query time, and then the content will be merged based on name.
Let me see if I get this correctly. You're saying that if I publish a new version of a category, the old one will still be considered?
(In reply to comment #11) > Let me see if I get this correctly. You're saying that if I publish a new > version of a category, the old one will still be considered? > On the UI side, all categories are collected in the queryable using a set. So non-equal IU's (those IU's with distinct id/version) will be collected. The UI then post-processes this set and merges all same-named IUs in one UI node. So AFAIK, multiple versions of a category in the same repo would be considered, unless the publisher does something at publish time to get rid of the old versions. At one time, I think we discussed the possibility that the UI could query the latest version of each category from each queryable, but we'd have to get the semantics of the query right, so that the latest version from each repo (not the latest in all of them) would be considered. I don't think we knew at that time how the publisher would handle this situation and whether this was needed on the UI side. All of this has been rather late-breaking, so I'm not sure where we ended up with that issue. Ian?
> 3. If they have different id but the same name, both will be used and they > will be aggregated in the UI. I tried that, and it works fine. Thomas, thanks for the hint.
