This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Summary: | Remove Usage Statistics from platform | ||
---|---|---|---|
Product: | ide | Reporter: | Lukas Hasik <lhasik> |
Component: | Logger | Assignee: | mslama <mslama> |
Status: | VERIFIED FIXED | ||
Severity: | blocker | CC: | jchalupa, mmirilovic, tomwheeler |
Priority: | P1 | ||
Version: | 6.x | ||
Hardware: | All | ||
OS: | All | ||
Issue Type: | DEFECT | Exception Reporter: |
Description
Lukas Hasik
2008-08-22 13:45:56 UTC
Actually, it seems to me the nb6.5 cluster might be a more appropriate place since that is where all NetBeans-specific branding typically goes. We do use parts of the ide cluster such as project support for our applications. Of course, I know how to patch the code to remove this subpanel if it continues to remain there, but one of the strongest selling points of the platform is that you *don't* have to patch the code. I have been working on the platform for more than three years now and the only times I have actually had to patch the code were to backport a bug fix for an issue that has already been submitted. Anything from the platform that I don't want in my app can be excluded declaratively, whether through the suite's platform.properties, suite branding, hidden from a module's layer.xml or replaced via the Lookup and service registration. If this makes it into the final release and can not be excluded declaratively, I'm confident I will be asked to remove it from our platform applications and expect that many (perhaps most) other developers using the platform worldwide would be asked to do the same or will simply not upgrade to 6.5. Making developers patch the platform sources to remove something unwanted is without precedent as I've described, but it is also a dangerous path to travel down because once you've set up your build process to apply one patch, applying a few more requires almost no effort. And that has the very real possibility of leading to forks which NetBeans has fortunately been able to avoid so far. After re-reading the last paragraph I wrote, it seems to come off as perhaps a bit threatening and that is not at all how I meant it. What I meant was that by making potentially thousands of platform developers who have never needed to patch their code start doing so to remove something that they don't want, it gives the tools, skills and temptation for them to make lots of other changes in relative isolation from one another. Although the license would probably require those changes to be submitted back to netbeans.org, dealing with a flood of such changes can become unmanageable. That greatly increases the risk of fragmenting the platform which, given NetBeans flexible architecture, has previously not been much of a risk. General tab in Options dialog is implemented in core.ui ie. platform. Actual code performing statistics collection/upload is not in platform. We will discuss how to fix this. I will try to show statistics UI only when system property set in logger will be set. This property will be set in logger module restored method. That seems like a reasonable solution to me, Marek. Fixed a53ffd03802f System property "nb.show.statistics.ui" is set in uihandler. If this property is set Usage statistics UI is shown in General panel. This property contains key name used to store flag true/false if usage statistics are collected. Verified in Hudson JavaSE trunk build #3619. Thanks for addressing this so quickly -- I should have no problem upgrading to the 6.5 platform now, or recommending to others that they do the same. Integrated into 'main-golden', available in build *200808300201* on http://bits.netbeans.org/dev/nightly/ Changeset: http://hg.netbeans.org/main/rev/a53ffd03802f User: Marek Slama <mslama@netbeans.org> Log: #144853: Show Usage statistics UI only in IDE not in Platform. |