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.
After create JavaHelp Help Set file module-about.html contain: <link rel="stylesheet" href="nbdocs:/org/netbeans/modules/usersguide/ide.css" type="text/css"> should be (slash added): <link rel="stylesheet" href="nbdocs://org/netbeans/modules/usersguide/ide.css" type="text/css"> Wrong link cause message: WARNING [org.netbeans.core.startup.InstalledFileLocatorImpl]: module org.netbeans.modules.usersguide in /usr/local/netbeans-7.1/ide does not own docs/org/netbeans/modules/usersguide/ide.css at org.netbeans.modules.javahelp.NbDocsStreamHandler$NbDocsURLConnection.connect(NbDocsStreamHandler.java:161)
The current URL is OK, though nbdocs://org.netbeans.modules.usersguide/org/netbeans/modules/usersguide/ide.css is better. nbdocs://org/netbeans/modules/usersguide/ide.css is wrong (host field set to "org" makes no sense). I do not get such a warning in a dev build, either in a standalone module (loaded against complete ide, so userguide module is present) or in a platform app (where this module is not present). ide/update_tracking/org-netbeans-modules-usersguide.xml does list <file crc="..." name="docs/org/netbeans/modules/usersguide/ide.css"/> in my dev build; but in a NB 7.1 build it does not. So something went wrong in the production build, possibly during localization.
The actual file is there in the cluster, so it is the update tracking metadata which is wrong.
http://dlc.sun.com.edgesuite.net/netbeans/updates/7.1/uc/final/distribution/modules/ide/org-netbeans-modules-usersguide.nbm does contain netbeans/docs/org/netbeans/modules/usersguide/ide.css as expected. http://download.netbeans.org/netbeans/7.1/final/zip/netbeans-7.1-201112071828-ml-javase.zip has the incorrect update tracking file, so the problem is not with the installer, but really with the production build.
Created attachment 115200 [details] /tmp/ducf.xml with numerous failures Result of: cd /tmp unzip netbeans-7.1-201112071828-ml-javase.zip ant -f /space/src/nb/main/build.xml -Dnb.build.dir=/tmp -Dnetbeans.dest.dir=/tmp/netbeans clean-untracked-files
Seems that */update_tracking/*.xml in NB 7.1 is badly broken: **/*.jar and config/Modules/*.xml are included but everything else is missing. (Perhaps caused by a mistake in the fix for bug #133901?) This means there could be problems installing updates. I am not sure how AU behaves when some files in the cluster are not listed as owned by any modules, and you try to install an updated NBM containing one of these files - does it quietly overwrite the existing file? If so, update problems should be rare. The update will still be incorrect in case the new version of the module omits a file formerly present. Another problem is that Ant-based module suites using NB 7.1 will omit various files from the ZIP distribution and so on. For example, if you make a new "NetBeans Modules > NetBeans Platform Application", set it to 7.1 as the platform, include all modules in the platform cluster, and Package as > ZIP Distribution, in the resulting dist/*.zip you will not have */platform/VERSION.txt which is supposed to be supplied by org.netbeans.modules.core.kit. This particular file is not important, but others are. For some reason I do not understand, platform/lib/nbexec does get created, but for example modules/lib/x86/jnidispatch.dll is missing - so when you try to do fancy window system stuff with the app as run from an unpacked ZIP, you get errors like INFO [org.netbeans.core.windows.view.dnd.DragAndDropFeedbackVisualizer] java.lang.UnsatisfiedLinkError: libjawt.so: cannot open shared object file: No such file or directory at com.sun.jna.Native.getWindowHandle0(Native Method) at com.sun.jna.Native.getComponentID(Native.java:268) at com.sun.jna.platform.WindowUtils$X11WindowUtils.getDrawable(WindowUtils.java:1296) at com.sun.jna.platform.WindowUtils$X11WindowUtils.access$800(WindowUtils.java:1117) at com.sun.jna.platform.WindowUtils$X11WindowUtils$2.run(WindowUtils.java:1316) at com.sun.jna.platform.WindowUtils$NativeWindowUtils$2.hierarchyChanged(WindowUtils.java:365) at java.awt.AWTEventMulticaster.hierarchyChanged(AWTEventMulticaster.java:498) at .... at java.awt.Window.setVisible(Window.java:1013) [catch] at org.netbeans.core.windows.view.dnd.DragAndDropFeedbackVisualizer.start(DragAndDropFeedbackVisualizer.java:147) (Maven-based Platform apps are not affected since they reconstruct the Platform via NBM.)
(In reply to comment #5) > For some reason I do not understand, platform/lib/nbexec does get created Special-cased in suite.xml#copy-nbexec, though I am not sure why.
May not be a true P1 since there is not much that can be done about it now - anyone who downloaded 7.1 has incorrect update tracking files. Obviously the problem in the build scripts must be fixed before making another public release. Whether a 7.1.1 patch update could retroactively fix the problem, I am not sure - you would have to issue updates for a large number of modules whose code was not changed in the branch, just to force correct tracking information to be written. (This is assuming, as above, that AU will permit an NBM to overwrite an untracked file.) (In reply to comment #5) > Ant-based module suites using NB 7.1 will omit various files [...] > > (Maven-based Platform apps are not affected since they reconstruct the Platform > via NBM.) Also Ant-based Platform apps using autoupdate.catalog.url=http://updates.netbeans.org/netbeans/updates/7.1/uc/final/distribution/catalog.xml.gz are not affected, for the same reason - only affects apps built against a complete downloaded 7.1 installation (the default case).
Integrated into 'main-golden', will be available in build *201201250600* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/222271911e01 User: Jesse Glick <jglick@netbeans.org> Log: Best to include module name in host field (mentioned in #207426).
(In reply to comment #7) > Whether a 7.1.1 patch update could retroactively fix the problem, I am not sure > - you would have to issue updates for a large number of modules whose code was > not changed in the branch, just to force correct tracking information to be > written. (This is assuming, as above, that AU will permit an NBM to overwrite > an untracked file.) Ok, removing from the list of issues for 7.1
Still an issue for 7.2? PetrG, Jesse, who will fix it and how?
Up to Petr to determine why the 7.1 production build got broken, whether 7.1.1 was similarly broken, and whether 7.1.2 and 7.2 will be better. Also to ensure that the production build script runs the equivalent of the test shown in comment #4 to prevent any future regressions. As to fixing the symptoms for 7.1 users (including those who downloaded 7.1 and updated to 7.1.x), it is up to the AU owner to determine whether we can retroactively correct it. Until then, application development based on the 7.1 Platform is impeded, and there may be other symptoms.
bc8b8ae8bc75 mentions this bug but cannot be anything like a complete fix for it.
Integrated into 'main-golden', will be available in build *201205090400* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/bc8b8ae8bc75 User: PGebauer <pgebauer@netbeans.org> Log: #207426 - NB 7.1 */update_tracking/*.xml omit many files
Integrated into 'main-golden', will be available in build *201205160400* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/9683a3daac6a User: PGebauer <pgebauer@netbeans.org> Log: #207426 - NB 7.1 */update_tracking/*.xml omit many files
Somebody from QA should do thorough check of every ML update tracking file.
Before QA spends time on it, did you run clean-untracked-files as described in comment #4 to check your own work, confirming that it fails without your changes and passes with them?