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.
Discovered as a result of conversations with Richard S. Hall. If you create e.g. FeedReader sample using a dev build of the IDE, and OSGi > Build Bundles, the manifest of build/osgi/org.netbeans.core.windows-*.jar correctly states vvvvvvvvvvvvvvv Import-Package: javax.accessibility, javax.swing, javax.swing.border, javax.swing.event, javax.swing.plaf, javax.swing.plaf.basic, javax.sw ing.plaf.metal, javax.swing.plaf.synth, javax.swing.text, javax.swing .tree, org.xml.sax, org.xml.sax.helpers But if you do the same using 6.9 RC1, it states vv Import-Package: javax.accessibility, javax.swing.border, javax.swing.e vent, javax.swing.plaf, javax.swing.plaf.basic, javax.swing.plaf.meta l, javax.swing.plaf.synth, javax.swing.text, javax.swing.tree, org.xm l.sax, org.xml.sax.helpers The missing import of javax.swing does not appear to cause any ill effect on the Felix Framework 2.0.3 shipped with the IDE, and thus with the Run in Felix action, but it apparently causes NoClassDefFoundError's under Felix 2.1.0-SNAPSHOT, thus preventing the main window from appearing. Since Build Bundles is intended to create a set of compliant bundles that could be run using any container, this would be a P1 problem. The cause seems to be that release engineering, when creating an official build, sets the build number to e.g. "201005242201" (a date). MakeOSGi sees an OpenIDE-Module-Implementation-Version which is an integer, decides that someone might have an implementation dependency on this module, and exports all packages found in the JAR. Since org.netbeans.swing.tabcontrol includes javax.swing.Painter (and com.sun.java.swing.Painter) from JDK 7, it exports javax.swing; org.netbeans.core.windows, with a dep on tabcontrol, uses javax.swing.JFrame but MakeOSGi thinks it is getting this package import from a bundle dependency on tabcontrol rather than the JRE, and thus does not bother to import it. The bug does not manifest itself in development builds, where the Mercurial changeset is included in the build number, e.g. "100526-2dffbc8be195". One fix would be to treat long digit sequences (4+ digits?) as opaque strings possibly referring to dates, rather than as numbers. Sort of hackish - what if someone really was using 1234 as a number? (Though usually these versions are <10.) Another fix would be to ignore numeric OpenIDE-Module-Implementation-Version when OpenIDE-Module-Build-Version is unset, since an explicit OpenIDE-Module-Implementation-Version in manifest.mf causes JarWithModuleAttributes to insert OpenIDE-Module-Build-Version for diagnostic purposes; OpenIDE-Module-Build-Version is otherwise unset since OpenIDE-Module-Implementation-Version contains the general build number. (For historical reasons these two attributes overlap in semantics.) This should work reliably for any module built using the standard build harness, though legal modules constructed by other means could fail to be translated correctly.
I don't know if this is 69_HR_FIX_CANDIDATE or 6.9.1_CANDIDATE. Even official nightly builds suffer from this problem (builds from source do not, assuming you did not pass -Dbuild.number=...). Builds from http://deadlock.netbeans.org/hudson/job/nbms-and-javadoc/lastSuccessfulBuild/artifact/nbbuild/dist/ seem to be OK: you can download, unpack, and run the -minimal.zip (bin/netbeans), add NetBeans Plugin Development using Tools > Plugin Manager, and proceed.
core-main #5ea43eeb77de
Integrated into 'main-golden', will be available in build *201005270001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/5ea43eeb77de User: Jesse Glick <jglick@netbeans.org> Log: #186755: Incorrect OSGi bundle translation when platform is an official release
Marking as 6.9 candidate. Tomasi, can you help with verification?
release69 #ed59df3fafbf
i can. to make this clear, steps to reproduce are: 1) create simple netbeans platform app (e.g. feedreader) 2) build osgi bundles 3) place those bundles into Felix 2.1.0-SNAPSHOT container right?
Exact steps to reproduce and verify: 1. Get release69 sources prior to fix. 2. ant -Dcluster.config=basic -Dbuildnumber=20100527 3. Check out https://svn.apache.org/repos/asf/felix/trunk/framework/ & mvn install. 4. cp ~/.m2/repository/org/apache/felix/org.apache.felix.framework/2.1.0-SNAPSHOT/org.apache.felix.framework-2.1.0-SNAPSHOT.jar nbbuild/netbeans/platform/modules/ext/felix-2.0.3.jar 5. ant tryme 6. Make FeedReader sample. 7. OSGi > Run in Felix. The splash screen will come up but then some NoClassDefFoundError's will be printed and the main window will not appear. 8. Kill process and shut down IDE. 9. Update to fix changeset. 10. ant bootstrap && ant -Dcluster.config=basic -Dbuildnumber=20100527 -f apisupport.harness/build.xml 11. ant tryme 12. Clean All, then Run in Felix again. Now the FR app window should appear normally without error.
thanks. Verified in release69.