Community
Participate
Working Groups
in i0413 With a target def that includes a number of different locations and features, using the "features" radio button on the Content page seems to disable the ability to show the content by location.
sorry, that was incomplete. Viewing features by location is just as relevant as viewing bundles by location. In fact, perhaps even more so since features are the things that the users select when populating from the various locations
We can investigate this further in RC1, but can't guarantee there will be time to work on this. It is difficult to add another level to the tree structure because of the "Other plug-ins" element.
I am getting the impression that the Manage using Features setting is supposed to show children here. I am certainly not seeing this. Is there another issue or am I just not seeing? The word "using" is confusing here. Am I manageing features or not? If yes then sup with the Other plugins stuff? If no then where are my feature children?
(In reply to comment #3) > I am getting the impression that the Manage using Features setting is supposed > to show children here. I am certainly not seeing this. Is there another issue > or am I just not seeing? The word "using" is confusing here. Am I manageing > features or not? If yes then sup with the Other plugins stuff? If no then where > are my feature children? You are selecting features (bundle groups) to include in your target when you "manage with features". The "other" stuff allows you to add additional bundles that are not part of a feature (in case you need to add one extra thing that is not part of a feature).
(Forgot to mention, we aren't intending to display bundles under the feature nodes in the tree)
Ok. I understand now but suggest that the current behaviour is unexpected ( at least by me). If you select manage by feature then you should really only see the features. Showing a "random" collection of bundles was confusing. I would have expected those to be shown when managing by bundle. OTOH, if you really want to show the Other Plugins, then it would be consistent to show the children of the features. At least in theory that should be very straight forward to do. Then you can have the features with children and the un-featured plugins under Other Plugins (or perhaps "Plugins not in Features") As mentioned in another bug, the current behaviour feels like an odd mix.
I agree that it would be nice to show the bundles included in a feature. Part of the reason we have the current UI, is that the check box tree does not work nicely for this - i.e. if you're managing by features, you get all of a feature - so to present check boxes for the bundles under a feature is misleading (especially if the user cannot check/un-check them). For "others" it makes sense to be able to check/un-check since they are just 'add ons'.
I understand what you are saying about features and unchecking the children but am not 100% sure I agree. Remember, we are not setting up a runnable configuration here. We are describing the set of things that will be available to develop against. From there we make runnable things. It may, for example, be that in my runnable world I actually don't use features at all. It may also be that I write my own features. If you as a producer supply a feature with the best of intentions but I as a consumer don't like your choice of bundle X, Y or Z in the feature, the current model forces the user to opt out of feature based management altogether. In short, it could be quite reasonable to navigate the target by feature and deselect some elements of a feature. Sure that feature *may* not longer work (the deselected bundles may be supplied by some other feature) but it is not even sure that the user wants the feature anyway. We can go back and forth on that one. I still find it quite confusing/surprising to say "manage using features" and then to see a list of mostly features but with a few bundles thrown in.
On the runtime side there are definite use cases for supporting the addition of individual bundles. For example, you want to run a product which is delivered as a set of features and some tests which are not - so you select your features and toss in the test bundles. (We are adding support in launch configs to add individual bundles to a feature launch). On the development side, I could imagine a similar scenario where most of your target is delivered as features, but perhaps a test harness or test support classes are not. Being able to add in select bundles increases the flexibility of the "feature" (sorry for the overloaded term).
OH yes, I completely agree and have been asking for this sort of thing in product files for quite some years. The bug is not questioning that but rather the reverse, the assumption that features are containers. Features are convenient groupings. This is especially true in the target context. There will be all manner of features that producers think are interesting but which consumers want to subset/augment. It is very convenient as you say to select whole features etc. The problem is that that approach does not scale to when someone wants to subset. As soon as they want that they drop off a cliff and are back to managing a flat list of 100s or 1000s of bundles. If on the other hand you think of features in this workflow as "virtual locations" then you can enable/disable them and subset. There need not be any workflow cliff. The simple case is still simple and the advanced cases are doable without a paradigm shift.
Not enough time to look at in 3.6.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
Please remove the stalebug flag, if this issue is still relevant and can be reproduced on the latest release.
