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.
steps to reproduce the problem 1. make a suite project. 2. make it standalone application. 3. try to build it with BUILD ZIP DISTRIBUTION option. This error appear: /usr/share/netbeans/6.0.1/harness/suite.xml:197: Warning: Could not find file /usr/share/netbeans/6.0.1/harness/launchers/app.exe to copy. BUILD FAILED (total time: 1 second) OS: ubuntu hardy heron Netbeans 6.0.1 installed from ubuntu repository's
reproducible on 6.0.1 from Ubuntu repository ...
According to http://packages.ubuntu.com/hardy/all/libnb-platform7-devel-java/filelist the package is incomplete as it is lacking app.exe and app_w.exe. Reassigning to the package maintainer.
Yes due to package policy we had to remove all binary files from source package and we are not able to build these exe files on Linux from sources. We will have to patch suite.xml for package not to fail when it does not find these exe files.
Unfortunate. This means that Ubuntu users will not be able to create cross-platform application ZIPs. Try failonerror="false" for the *.exe. If that works, feel free to commit the same change to the trunk; should be harmless for regular NB distributions.
Or we could deliver the exe binaries to those users via UC. Simply increasing spec version of the appropriate modules and putting them on UC.
> Or we could deliver the exe binaries to those users via UC. Simply increasing spec version of the appropriate modules > and putting them on UC. I agree. Could we do that for NB 6.0.1 ?
I can't say I'm comfortable with intentionally overriding a package installed by the Ubuntu package manager. Generally I would expect that anything installed as a .deb package should not be overridable by some app-specific packaging mechanism. Anyway I'm not even sure the proposed solution would work at all. AU will dump the new harness in the userdir. (It had better not physically overwrite the .deb-installed files or the user will be unable to use the normal Package Manager to deal with NetBeans, which defeats the purpose of distributing it in this way!) But apisupport does not look for a harness in other places. It only considers the version installed in the normal place. Cf. #72315; nbm.is.global=true for apisupport.harness to ensure this when installed from AU.
I would still suggest failonerror="false" for the *.exe as a simpler and much safer alternative. Anyone who really needs to create a ZIP which can work on Windows can simply download the NB Platform and configure it in NB Platform Manager.
Another option is to try "Minimalist GNU win32 (cross) compiler" (package mingw32) to compile app.exe and app_w.exe from sources on Debian/Ubuntu. I will look at it.
I was able to build app launchers using mingw. I tested both lauchers (app.exe and app_w.exe) with suite app on W2K and both started fine. I will attach modified Makefile which can be used as base for building package for Linux distros. Passing to installer team. Launchers are located at apisupport.harness/windows-launcher-src. I you think it is useful I can add modified Makefile to repository or merge it with existing Makefile as only CC and WINDRES variables would be added and modified according to platform used to build launchers. For Ubuntu cross-platform compiler for Windows package is mingw32 (and mingw32-binutils, mingw32-runtime on which mingw32 depends on so for just mingw32 can be used as build dependency). This can be used for NB 6.1 packaging so I think we need not patch for suite.xml. For packages there are 2 options now: a) use mingw to compile launchers b) patch suite.xml if variant a) is not possible for whatever reason.
Created attachment 65124 [details] Makefile for mingw
Issue is fixed in NetBeans 6.1 packages.