[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- From: Susan Franklin McCourt <susan_franklin@xxxxxxxxxx>
- Date: Mon, 26 Jan 2009 09:00:49 -0800
- Delivered-to: email@example.com
There's been discussion of categories in the last couple of p2 calls, as well as some open bugs on these issues...
Issue of not showing IU's that aren't categorized. You should see all IU's (that are generated with the group property) if you are not grouping by category. If you are grouping by category, you'll only see "Uncategorized" things that specifically had this category generated at publish time. There is some explanation/ongoing discussion of this in bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=262009.
1 & 2 - qualified names, id's, versions, etc.
3 - when you say we invite the user to install a category, do you mean the ability to check the category and it checks all of the iu's underneath? Technically speaking, we never install a category, nor do we intend to invite it. I think the problem here is the lack of auto-expansion of categories.
4 - there has been discussion for some time about the ability to support repo aggregators who provide their own categorization, independent of the publisher's view of categories. I agree it feels "backwards" (and in fact, makes finding uncategorized things quite clunky) to rely on the categories themselves to enumerate their content, but the intention was that aggregation and grouping for the same IU's could be different in different repos, and this should be done without having to modify the IU itself.
Thomas Hallgren <thomas@xxxxxxx>
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.
p2-dev mailing list