| Re: [p2-dev] Categories |
|
The change toward that behavior got discussed in the call before being implemented (it dates back from before Xmas). The key point was that p2 was, in comparison to UM, showing way too much content since it showed things that were not appearing in the site.xml (site.xml can have categorized content and uncategorized content, but a site can contain more than features) and revealed undesired content (e.g. hidden features).
David M Williams wrote:
> least show up under 'Uncategorized'. I suspect this is one of the effects of bug 25604 ... [ui] UI should no longer be creating an "Uncategorized" category https://bugs.eclipse.org/bugs/show_bug.cgi?id=256044 - thomas
Hi, I discovered that an attempt to install from a MetadataRepository that contains only features and bundles will not work. The UM will not display IU's unless they are found below a category. This seems to be true regardless of if I list by category or not (I'm using the 3.5 integration build from 22/1). I would expect uncategorized IU's to at least show up under 'Uncategorized'. The current use of categories as IU's is of some concern to me. I can see several cons with that approach: 1. Categories in general are not using qualified names and this results in collisions when aggregating repositories. We often see categories named 'core', 'optional', 'tools' etc. 2. Categories are not versioned so we cannot really track how they change over time. 3. Inviting users to install a category is often counter intuitive. They may contain several mutually exclusive choices (Subclipse and Subversive in the SVN category for instance) or a bunch of features listed under "Optional". You're not supposed to install "Optional". The idea is that you make your own pick from that category. 4. Categorization would make a lot of sense if you (the IU publisher) were able to hook into well known categories when publishing. As it is now, you must own the category and the only thing it can contain is listed in its required capabilities, essentially making the category useless (and occupied) for everyone else. I think that category affinity should be a provided capability (or property) in the respective IU's that "belongs" to the category. Having the category itself list its content as requirements is doing it backwards. Regards, Thomas Hallgren _______________________________________________ p2-dev mailing list p2-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/p2-dev _______________________________________________ p2-dev mailing list p2-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/p2-dev p2-dev mailing list p2-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/p2-dev |
