[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- From: Thomas Hallgren <thomas@xxxxxxx>
- Date: Mon, 26 Jan 2009 21:12:43 +0100
- Delivered-to: email@example.com
- User-agent: Thunderbird 18.104.22.168 (X11/20090105)
Susan Franklin McCourt wrote:
This is probably the thing that I'd consider the most problematic.
Consider the case when you install from several disparate repositories.
The first repository that defines a category name will block all other
repositories using that same name. There's no way different vendors can
agree on publishing things under a common category unless they jointly
maintain that category in a joint repository. Doesn't that defeat the
purpose of categorization? If the only purpose with the category is to
group things together in the scope of one repository, why not just use a
feature for that?
There's been discussion of categories in the last couple of p2 calls,
as well as some open bugs on these issues...
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.
If I understood whats in
https://bugs.eclipse.org/bugs/show_bug.cgi?id=261104 correctly, the UI
currently merges the category IU's together when they have the same ID.
To me it looks like you are using the IU's in ways that I don't think it
was intended. As the name suggests, it's something installable. Here you
merge them just to group things together in the UI and they're not
really installable. Why don't you simple use a property where a IU can
list the categories that it thinks it belongs to? I'm confused...