Community
Participate
Working Groups
Build ID: 20090619-0625 Steps To Reproduce: Hello, If certain items are not grouped then they are not displayed if the flag "Group items by category" is set in the update manager. I suggest that you have another node "Non-grouped items" which contains all items without group. This way the user can immediately see all features which are available. Best regards, Lars
We've had this discussion many times across the 3.5 development cycle. The problem is that site producers want to control which non-grouped items appear. Some of them should not. In Eclipse 3.4.x, the p2 UI showed everything in an "Uncategorized" node, and this was considered a bug. To fix this problem, we decided that site producers must categorize those things they want visible, and mark as "Uncategorized" the others. Anything not marked by the producer will be hidden. There is a summary of the issues in http://wiki.eclipse.org/Equinox/p2/Proposals/Category_Management as well as an extended discussion in bug 262009. The resolution for 3.5 was that the site producer needs to ensure that they mark the features that should be visible as "Uncategorized." This has been a controversial topic, and I would like to understand your request better. Is there a particular site that causes you a problem? It's possible that the category generation for that site needs to be updated. Or are you an update site producer who wants to ensure certain things are visible?
Thank you for the detailed explanation. This bug was triggered by the missing category for GEF / ZEF in the Eclipse Galileo Update Site (https://bugs.eclipse.org/bugs/show_bug.cgi?id=280750). I personally think that the category should not contain another sementic rather then grouping. If someone wants to hide something then there should be a separate flag (e.g. visible). Re-using a field for two purposes (grouping and hidding) is in my opinion confusing. So personally I would plead for the old behavior which I find less confusing. All non categorized items should be displayed as "Uncategorized". Hiding a feature should be supported by its own new flag. But I respect that you have discussed this already several times and changed it, so in case you believe the current behavior is better then please close this bug.
> I personally think that the category should not contain another sementic rather > then grouping. If someone wants to hide something then there should be a > separate flag (e.g. visible). So the question is, should GEF be visible? always? The example we have been using is a small RCP app that is deployed to bankers. They can install "Credit Tools", "Accounting Tools" or "Mortgage Tools". Since it is a great tool, it's built on EMF, RCP, BIRT, GEF, Equinox, Jetty, etc.. The IUs come from the Galileo repo, and if we associated visibility with these IUs, then they would see a bunch of implementation details. An uncategorized category suffers from the same problem. Should the bankers install this GEF thing that they have never heard of? Instead, you can provide your own categorization for your customers.
I believe it would be good to have the option to hide things explicitly. But I don't think that re-using the category is the best way of doing this. I believe the better solution would be have the functionality to tell p2 explicitly "this feature should be hidden". I'm just providing my opinion here; if the p2 developer team believe the current behavior is sufficient I'm fine with it. :-) The current behavior is in my opinion a good workaround for your use-case.
(In reply to comment #4) > I believe it would be good to have the option to hide things explicitly. It's hard to associate "hide this thing" with the "thing itself" because you never know what use cases you will have later. The IUs (the things) are immutable, so you really shouldn't change these values once you have them written. > > But I don't think that re-using the category is the best way of doing this. I > believe the better solution would be have the functionality to tell p2 > explicitly "this feature should be hidden". The idea is not to reuse the category. Instead simple have a repo with A, B, and C in it. Then you have a category repo that shows A and B. Your clients would then connect to that category repo to see A and B. You could create a different category repo that shows B and C (for a different group of users). In the end, A, B, and C are just the features and you craft different views onto them.
(In reply to comment #4) > I believe it would be good to have the option to hide things explicitly. > Controlling visibility is good but I think it should be done by annotating IU's as visible, not by hiding. A categorized feature could get this annotation by default. If things could be made visible using an annotation, we could make bundles directly installable. Products too. The visibility annotations should not be tailored to the "Install new software" wizard in the IDE. Any installer could benefit from this and some context sensitivity might be good. A stand alone installer would probably like to make products visible while the IDE wizard, already running in a product would like to hide them. A standard OSGi filter perhaps? That way, visibility depending on platform filters would be very easy to accomplish.
Hi Ian, thank for your explanation; you have convinced me. Best regards, Lars
*** Bug 282137 has been marked as a duplicate of this bug. ***
*** This bug has been marked as a duplicate of bug 262009 ***
