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.
Build: NetBeans IDE Dev (Build nbms-and-javadoc-7840-on-20110906) VM: Java HotSpot(TM) Client VM, 21.0-b17, Java(TM) SE Runtime Environment, 1.7.0-b147 OS: Windows XP User Comments: epdv: Please, add some more info (to which module this exception is related?), so I'll be able to file this bug for the module related. Stacktrace: java.lang.ClassCastException: java.util.TreeSet cannot be cast to org.openide.modules.ModuleInfo at org.netbeans.modules.modulemanager.ModuleBean$AllModulesBean.compare(ModuleBean.java:363) at java.util.TreeMap.getEntryUsingComparator(TreeMap.java:369) at java.util.TreeMap.getEntry(TreeMap.java:340) at java.util.TreeMap.remove(TreeMap.java:595) at java.util.TreeSet.remove(TreeSet.java:276) at org.netbeans.modules.modulemanager.ModuleBean$AllModulesBean.doEnable(ModuleBean.java:817)
Created attachment 110852 [details] stacktrace
This happens on "Resolve missing modules".
Don't know, if it really belongs to contrib - the problems where shown in MMR first, but seem to cause a number of additional problems (some modules seem to not load any more). See http://statistics.netbeans.org/analytics/exception.do?id=528109 Thus rising priority.
Don't know why, after some time I could now activate some modules. When I tried to activate BugZilla, NB wanted to download some eclipse modules and failed with this exception again. Probably the bug is eclipse module related?
As you know, recent daily builds of NetBeans (upcoming 7.1) can load OSGi bundles directly, the plugin Module Manager, MMR are not adjusted this fundamental change in NetBeans module system. Both plugins (MM, MMR) are just weekend projects, not part of NetBeans distribution, published on Update Center for plugins in Beta quality. I'm afraid I find free time to fix them in a short time. If are a volunteer, all patches are welcome. Regards.
(In reply to comment #5) > As you know, recent daily builds of NetBeans (upcoming 7.1) can load OSGi > bundles directly, ... Then this might be the problem: http://statistics.netbeans.org/analytics/detail.do?id=180961 > ... the plugin Module Manager, MMR are not adjusted this > fundamental change in NetBeans module system. Both plugins (MM, MMR) are just > weekend projects, not part of NetBeans distribution, published on Update Center > for plugins in Beta quality. I'm afraid I find free time to fix them in a short > time. If are a volunteer, all patches are welcome. Regards. Sorry, not yet worked with OSGi.
Created attachment 111267 [details] stacktrace
(In reply to comment #5) > As you know, recent daily builds of NetBeans (upcoming 7.1) can load OSGi > bundles directly, the plugin Module Manager, MMR are not adjusted this > fundamental change in NetBeans module system. Both plugins (MM, MMR) are just > weekend projects, not part of NetBeans distribution, published on Update Center > for plugins in Beta quality. I'm afraid I find free time to fix them in a short > time. If are a volunteer, all patches are welcome. Regards. That's *not* the problem - at least for this exception: class ModuleBean, line 817: realModules.remove(realModules); You're trying to remove a TreeSet<Module> from itself - probably You wanted to write: realModules.removeAll(realModules); ?
I've got some dependency problems related to org-eclipse-* (seems to be OSGi related). These problems seem to exist in Autoupdate, too. So, again, this bug is not related to OSGi, and MM seems not to be the source for OSGi problems: The problems seem to be caused by dependency checking in AU services module, already.
Created attachment 118917 [details] stacktrace
realModules.remove(realModules) is obviously wrong but realModules.removeAll(realModules) would not make any sense either. Who knows what this part of the catch block was supposed to be doing? It claims it will "try to enable a subset this time" but there is no code to compute such a subset. I think it can be deleted. The latest log file (#576826) shows some problem with dependencies of org.eclipse.mylyn.bugzilla.core, which precedes this CCE and is presumably its trigger. BTW reporter you are running a mixture of modules from various dev builds (not to mention lots of third-party modules which look to be long outdated). You need to download fresh complete dev builds to avoid untested combinations. Otherwise you are on your own: you can expect sundry exceptions and need to be evaluating them yourself.
core-main #3ac0b733c804
(In reply to comment #11) > [...] > > BTW reporter you are running a mixture of modules from various dev builds (not > to mention lots of third-party modules which look to be long outdated). You > need to download fresh complete dev builds to avoid untested combinations. > Otherwise you are on your own: you can expect sundry exceptions and need to be > evaluating them yourself. Most outdated modules are disabled because of missing dependencies, so this shouldn't hurt. If there are modules from different builds, the spec versions probably have never been updated, so AU doesn't work correctly. However, the installation causing the latest stacktrace (comment #10) has not been updated for 2 months, so this also may be the cause for the mixture of old and new modules (while update has been aborted because of the exception). Thank You for fixing the bug!