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.
Created attachment 113616 [details] IDE log. Chain of exceptions is thrown when running UI commit validation tests. The class IDECommitValidationTest is in java.kit module. Full stack trace in attached messages.log. SEVERE [org.netbeans.modules.netbinox]: framework event org.eclipse.mylyn.commons.net type 2 java.lang.NullPointerException Caused: org.osgi.framework.BundleException: Exception in org.eclipse.core.internal.net.Activator.start() of bundle org.eclipse.core.net. Caused: org.eclipse.core.runtime.internal.adaptor.EclipseLazyStarter$TerminatingClassNotFoundException: An error occurred while automatically activating bundle org.eclipse.core.net (81). Caused: java.lang.NoClassDefFoundError: org/eclipse/core/net/proxy/IProxyService Caused: org.osgi.framework.BundleException: Exception in org.eclipse.mylyn.internal.commons.net.CommonsNetPlugin.start() of bundle org.eclipse.mylyn.commons.net.
Not for 7.1?
Could be fixed by passing in startupArguments("--branding", "nb"), there is a bug 197066 to use this parameter automatically.
It appears in new 7.1 RC2 build 201111292200 (#6ac84b6073e5). Not reproducible in previous RC1 build 201111242103 (#0845e53258a4).
Caused by fix of bug 205019 - that is why it is not in RC1. I'd like to fix it by fixing bug 197066, but that needs some time. If there is just one failing test, then I suggest to fix it by adding addStartupArgument("--branding", "nb") to the test's initialization. See http://bits.netbeans.org/dev/javadoc/org-netbeans-modules-nbjunit/org/netbeans/junit/NbModuleSuite.Configuration.html#addStartupArgument(java.lang.String...) Jirko, you can fix it in release71 and leave it failing in trunk, imho. Then pass it back to me.
*** Bug 205713 has been marked as a duplicate of this bug. ***
Adding addStartupArgument("--branding", "nb") helps. But I think this exception appears whenever someone runs test using NbModuleSuite, doesn't it? Especially platform developers can face this issue. Would it be possible to rather somehow suppress/catch this exception in 7.1?
(In reply to comment #6) > I think this exception > appears whenever someone runs test using NbModuleSuite, doesn't it? Especially > platform developers can face this issue. Only if they are using the ide cluster, I think - that is where org.eclipse.equinox.security lives.
This is a patch that fixes the problem for me: http://bugzilla-attachments-197066.netbeans.org/bugzilla/attachment.cgi?id=113705 Especially its following part should go into 7.1 release. Without it even users of the IDE could see the NPE under some circumstances: diff -r f5508ddfc576 o.eclipse.equinox.common/nbproject/project.properties --- a/o.eclipse.equinox.common/nbproject/project.properties Thu Dec 01 08:50:37 2011 +0100 +++ b/o.eclipse.equinox.common/nbproject/project.properties Thu Dec 01 15:15:11 2011 +0100 @@ -1,3 +1,5 @@ release.external/org.eclipse.equinox.common-3.6.0.jar=modules/org-eclipse-equinox-common.jar is.autoload=true nbm.module.author=Tomas Stupka +module.startlevel=2 The patch also includes changes to apisupport.harness which may not be necessary for 7.1, Jesse please review. The patch does not check behavior of binary test distribution. QA please verify its behavior.
I tried the patch in trunk and the exception was never thrown regardless I run IDECommitValidationTest from the IDE or using binary distribution. When running from binary distribution testWriteAccess failed (see attached stack trace) but it seems unrelated.
Created attachment 113711 [details] testWriteAccess - stack trace
Yes, the failure is not related. It is caused by autoupdate kicking in after 15/30s and trying to do something. Best to modify the test to ignore this write attempt.
(In reply to comment #8) > +module.startlevel=2 OK as far as I am concerned; it seems reasonable that this core-sounding module should have a lower start level (2) than others (4). The one problem I can foresee is in an app which does not define a default start level for bundles yet uses Equinox bundles from the ide cluster, since a level of 2 will be higher than the default (right?). However o.eclipse.equinox.registry is already at 3 so such an app would just have to define a default level like the NB IDE does (and o.eclipse.equinox.common probably needs a strictly lower level than others to avoid random errors). Possibly the start level system should behave more sensibly out of the box so that 4 is automatically used as a default level (without any special branding) when Equinox rather than Felix is in use, though I am unsure whether this really make sense and how it would affect JDev or other cases; not for 7.1 anyway. > The patch also includes changes to apisupport.harness which may not be > necessary for 7.1 Those are already discussed in a separate issue (and I do not agree with some parts of that patch). For 7.1 it should suffice to just patch IDEValidation to explicitly set --branding nb.
Created attachment 113714 [details] new patch without changes to apisupport.harness As all our tests using NbModuleSuite throw the same exception, I'd rather fix them all - e.g. make sure that NetBeans.org projects are running with nb branding.
Created attachment 113716 [details] New patch with apichanges.xml
So in summary for 7.1: bug #197066 will be partly fixed (NbModuleSuite, projectized.xml, but no common.xml or apisupport.harness changes); #205653 will be fixed with an additional patch to o.eclipse.equinox.common startlevel (will commit as separate patch).
ergonomics#4edff56ac7d8 merged into release71 as 1dc1b1aa3207
Integrated into 'main-golden' Changeset: http://hg.netbeans.org/main-golden/rev/4edff56ac7d8 User: Jaroslav Tulach <jtulach@netbeans.org> Log: #205653: Always specify 'nb' as branding for netbeans.org NbModuleSuite tests
Still getting this exception in org.netbeans.test.profiler/ProfilerValidationTest/testProfilerMenus -> Reopening as it seems to be fixed for most cases -> lowering priority
This bug is fixed in the IDE. If you see it in tests, it may be because you don't have all necessary modules enabled. Definitely it is different bug.
*** Bug 206132 has been marked as a duplicate of this bug. ***
Filed bug 206468 for not yet fixed cases.