Community
Participate
Working Groups
3.8 M5. The 'Tracing' preference page feels odd: - The user has no clue what the currently shown options do. The names contain "debug", "tracing", "preferences". It's not obvious that those options are for the tracing plug-in only. At least the node name needs to be changed. - The UI allows to change the options for a bundle which 99% of the user don't care and on the other hand things he might expect to see (like the known debug options) aren't there. (I know why but for the user it's not clear). ==> Maybe we shouldn't show anything in there in the SDK. To me this rather looks like an example than something people are really interested in. The page should explain how to add new tracing options. Maybe with a link that points to documentation.
None of the Eclipse SDK components currently use the tracing options and there are no plans to do so during 3.8. Listing steps to hook into the page may be of benefit, but I don't think it will be sufficient. A few options: 1) Leave the page as is Hopefully some teams could use it in the next release. 2) Remove the options provided by tracing and put different text into the table when no tracing options are found The page would still feel like an example, but the page would be less confusing and encourages teams to support it 3) Remove the page contribution The page would still be available to products, but if WTP or other projects want to use it they would have to contribute it. If multiple projects contributed the page it would be even more confusing. This also reduced the visibility of the feature, which will prevent uptake.
-1 for 1) There are other options: 4) Remove the preference page contribution/extension from the registry on startup if there is not tracing contribution. 5) Show a different control/UI in the preference page if there is no tracing contribution, e.g. text with a link to the doc that explains how to add tracing. 6) Add a system property to enable the page (off by default) 7) Remove the entire bundle from the SDK. What I also don't like is that this bundle auto-starts without any value to 99% of the SDK users. We always recommend not to auto-start a bundle. So far the whole SDK only had two startup extensions. My vote would be to keep this as separate downloadable bundle for interested parties (7).
A key points seems to be whether we expect contributions from Eclipse components in the near feature (after 3.8). If no, then it's better to remove the bundle from the SDK (7). For 3.8 this is maybe the way to go. If we do want it to be used in Kepler, then it should stay, otherwise no one will jump on. It would actually surprise me if components do not have the need for configurable tracing in maintenance scenarios. I don't see why only third parties want to configure tracing but Eclipse teams don't ;) So maybe it's just a matter of missing awareness of the new feature. Have there been any roll-out activities amongst teams? Anyways the UI should contain a note saying that not all installed bundles/components are listed but only those that participate (2). The early startup behavior is a rather ugly thing, we should see how we can improve. I could imagine a new extension point in OSGi tracing that allows for registering a trace initializer or so on first access of DebugOptions. But the effect of tracing UI bundle to be loaded early would be nearly the same.
(In reply to comment #3) > A key points seems to be whether we expect contributions from Eclipse > components in the near feature (after 3.8). If no, then it's better to remove > the bundle from the SDK (7). For 3.8 this is maybe the way to go. > > If we do want it to be used in Kepler, then it should stay, otherwise no one > will jump on. It would actually surprise me if components do not have the > need This is a good point. We could offer it as a separate bundle for Juno and then put it back in during Kepler to give SDK components the opportunity to jump on board. If nothing happens until e.g. Kepler M5, we drop it again. > I don't see why only third > parties want to configure tracing but Eclipse teams don't ;) We use tracing extensively since the beginning, but in 99.9% in the context of debugging a problem i.e. with -debug plus a fine-tuned options file. Hot-switching while the app is running isn't really needed for that. In addition, we can set the tracing options in the launch configurations when we debug a target. See also bug 370402 how the new preference page adds confusion to the -debug scenario. > The early startup behavior is a rather ugly thing, we should see how we can > improve. I could imagine a new extension point in OSGi tracing that allows > > for > registering a trace initializer or so on first access of DebugOptions. But > the > effect of tracing UI bundle to be loaded early would be nearly the same. When I read "tracing UI" I would expect that this bundle is only loaded when the UI (i.e. the preference page) is opened. The options handling should be done at a lower layer and make sure that it plays well with -debug [optionsFile].
(In reply to comment #4) > (In reply to comment #3) > > A key points seems to be whether we expect contributions from Eclipse > > components in the near feature (after 3.8). If no, then it's better to remove > > the bundle from the SDK (7). For 3.8 this is maybe the way to go. > > > > If we do want it to be used in Kepler, then it should stay, otherwise no one > > will jump on. It would actually surprise me if components do not have the > > need > > This is a good point. We could offer it as a separate bundle for Juno and then > put it back in during Kepler to give SDK components the opportunity to jump on > board. If nothing happens until e.g. Kepler M5, we drop it again. > > > > I don't see why only third > > parties want to configure tracing but Eclipse teams don't ;) > > We use tracing extensively since the beginning, but in 99.9% in the context of > debugging a problem i.e. with -debug plus a fine-tuned options file. > Hot-switching while the app is running isn't really needed for that. In > addition, we can set the tracing options in the launch configurations when we > debug a target. See also bug 370402 how the new preference page adds confusion > to the -debug scenario. > > > > The early startup behavior is a rather ugly thing, we should see how we can > > improve. I could imagine a new extension point in OSGi tracing that allows > > > for > > registering a trace initializer or so on first access of DebugOptions. But > > the > > effect of tracing UI bundle to be loaded early would be nearly the same. > > When I read "tracing UI" I would expect that this bundle is only loaded when > the UI (i.e. the preference page) is opened. The options handling should be > done at a lower layer and make sure that it plays well with -debug > [optionsFile]. Handling trace persistence in core layer was actually rejected in the original discussion (https://bugs.eclipse.org/bugs/show_bug.cgi?id=296631#c40). This should maybe be reconsidered in the light of the -debug and startup issues.
(In reply to comment #2) > > 5) Show a different control/UI in the preference page if there is no tracing > contribution, e.g. text with a link to the doc that explains how to add > tracing. > +1 for this option. This way people will know the page is there, giving it exposure *and* directly the curious on how to contribute to it When testing the new support for platform debug I found some spots I think could be a bit better: 1. make the tree more hierarchical - i.e. everywhere there is a '/' in the option path should be another level in the tree, that way I can quickly turn on / off groups of options. It also mitigates the problem with the root 'debug' option as mentioned in bug 370604 comment #0. 2. provide some way for me to drive some (or all) of the UI for my options. This would allow me to do two things: (1) rename / label them as I see fit (2) possibly present different options. For (2), consider the presentationId option from debug.ui options; I would love to be able to present a list (combo - editable) of the currently active presentation ids so the user could quickly select / edit it and start tracing.
If we have more/real contributions (see bug 370604 and bug 370615), then we can save the time to implement 5. However, what we still need to fix before shipping this, is 1) Figure out how this plays together with the -debug [optionsFile] scenario. 2) Try to get rid of the auto-start. If the UI and the options handling would be in separate bundles, then this would be easy: those bundles supporting the dynamic options could simply pre-req the core tracing bundle. The UI tracing bundle would be loaded when the preference page is opened.
(In reply to comment #7) > However, what we still need to fix before shipping this, is > 1) Figure out how this plays together with the -debug [optionsFile] scenario. Covered by bug 370402, if using -debug we let Equinox handle it. Users can go to the preference page and override things. > 2) Try to get rid of the auto-start. I don't have a better solution than splitting the bundle.
> > 2) Try to get rid of the auto-start. > > I don't have a better solution than splitting the bundle. Yes, that would be the easiest way to go.
(In reply to comment #9) > > > 2) Try to get rid of the auto-start. > > > > I don't have a better solution than splitting the bundle. > > Yes, that would be the easiest way to go. What about having a DS component that consumes 1 or more DebugOptionsListener services. When one of these services is registered then your component would get activated.
(In reply to comment #10) > (In reply to comment #9) > > > > 2) Try to get rid of the auto-start. > > > > > > I don't have a better solution than splitting the bundle. > > > > Yes, that would be the easiest way to go. > > What about having a DS component that consumes 1 or more DebugOptionsListener > services. When one of these services is registered then your component would > get activated. I guess that's also fine. The UI portion of the bundle isn't too big and I verified that the UI classes aren't loaded on startup.
Created attachment 210879 [details] Replaced EarlyStartup by DS component
Here's a patch that replaces the early startup by a DS component as proposed above.
Fixed in master. I like this approach. There is one case that is not caught by the autoloading, where the DebugTrace is called each time, without ever registering a DeubgOptionsListener. Workbench UI plug-in does this. I will update it to register a listener, even if we don't end up using it. Also discovered that egit uses the trace API, so I will open a bug to register their options on the page. I will open a bug for clearing out the tracing plug-ins tracing and another to improve documentation.
Bug 371656 - eGit Tracing Bug 371657 - Cleanup tracing Bug 371658 - Document tracing
Verified in N20120215-2000.
