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.
OK I installed a plugin- the clipboard history plugin from here: http://plugins.netbeans.org/plugin/31336/history-clipboard Apparently it was no longer compatible with 7.2. NB refused to launch after I installed it and agreed to restart NB. OK Fair enough. The problem was it somehow hosed NB so that the issues never went away. Every time I tried to run NB it (NB) would cite a list of incompatiblities (involving the versions of editor libraries and "38 other problems") and ask me if I wanted to ignore them or exit. I chose ignore. NB stalled initing at "loading modules" thereafter. Everytime. So now it's p1 Netbeans is unusable. Here's the really bad part - I had to nuke my user prefs and all that jazz because uninstalling without choosing to nuke all that didn't result in NB being able to function again. So I had to do a FULL uninstall. Of course, I hate full uninstalls of anything because I just said buh-bye to all my macros, editor configurations all that busy set up crap that ends up taking hours to redo. Now it's p(-100) .. NB's is causing me genuine pain and wasting my time. I have to think that plugins are somehow allowed to mutate files and the pre-mutation version of those files is NOT saved by NB. The end user cannot return to the pre-plugin install state if anything goes terribly wrong- for instance NB never loads again. It's too much to expect the end user to be able to troubleshoot this kind of thing. I know I could have probably saved my prefs somehow some way by copying files and then replacing them again, but how many files and where are they located and what are their names? I'm not sleuthing all that down and hoping I get it right.... I'll take the sure thing and nuke everything and just start over. That's the course of action most people will choose. NB ought to save off whatever state it needs to save off before a plugin is taken up and be able to totally revert to the pre-plugin state. So when NB restarts with new plugins, a dialog would pop up saying "do you want to install these plugins? If NB has never successfully loaded and run with those plugins. Answering "no" would result in a behind-the-scenes reversion of plugin-altered files to their pre-plugin state. That way after the first time a plugin prevents NB from loading properly, the user can escape. If the plugin screws NB up after it loads for the first time or sometime thereafter, there ought to be a way to blame the plugin, tell the user the plugin screwed up and is being disabled, and then revert to pre-plugin state. Plugins are a huge vulnerability to the perceived goodness of the IDE (or rich client) b/c they're where just *anyone* can do just *anything*. In this sense it represents a total break down of QA. You can't stop plugins from hosing things, but you should have a fail safe fall back procedure that firewalls the damage they can do to NB's reputation . HTH