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.
When you select build Mac OS X build on a Netbeans platform build, the generated script fails when running on Mac OS X v10.4.7 and others. This was discussed both on and off the dev@openide.org mailing list. Fabrizio Giudici, helped me offlist to come up with a solution.
There was an error in the generated script, concerning the path of 'progdir'. A quick fix was: 1. find: progdir=`dirname "$PRG"` 2. replace it with: progdir=`dirname "$PRG"`/../Resources/addressbook/addressbook where 'addressbook' is the name of the application. I'm not sure if the fix is right in the setting of progdir or if it should be applied elsewhere, perhaps where other paths are computed.
Reassigning to "installer" for evaluation.
I am not sure this is to do with the installer at all. It is more do do with the generated script that is produced when Netbeans 6.0 produces a Mac OS X application.
I do not know what does it have with installer either. Please could you exactly say how to reproduce this problem so it is dispatched to correct component? I do not know what you mean by 'When you select build Mac OS X build on a Netbeans platform build'.
My appologies if I wasn't clear. I have been develioping an application which is built on the netbeasn platform. I needed to create a zip distribution and a Mac OS X distribution. On my Module Suite I right clicked and selected Build Mac OS X application. The result was the zipped and sent to a friend for testing. He came back saying that the application did not even start. I hope this helps.
Thanks Passing to API support.
Milos do you handle Mac build issues?
sorry, it seems to work for me. 1. I created a new suite project, set the name of app to "milos". (without doing so, the app could not be created) 2. created the macosx application 3. created a zip file. 4. moved both to different location. 5. the macosx bundle started correctly from finder 6. after unzipping, the zipped app worked fine from command line. i'm having 10.4.7 Macosx + jdk 1.5, tried on a trunk 6.0 build (post milestone4) please reopen after adding detailed steps to reproduce the issue.
Hi Milos Sorry it has been a long time since original post. I created another Mac OS X distribution based on my application and my loyal tester says that it fails. I have an application based on the Netbeans platform, all I have done is selected Build Mac OS X application from the menu. My Tester says that there is not even a flicker and quits before doing anything. I can create a new application and make that available for testing if that will help the process. To create the distribution I used Netbeans 6.0 dev daily build of the 30th November. 1. I just created a new application called the Test. 2. Created the Mac OS X application 3. Made the application available for download 4. Got report back saying that the application did not start. David
yup, providing a sample app that doesn't work could help. What operating system do you create the Macosx bundle on? is it mac or some other platform?
I am using Linux to run the IDE and create the build. Please try the following link for a sample application. http://86.133.177.200/software/test-software and download the nb6 mac build. Hope this helps
I get this error on the console and the app exist immediately as reported. ===== Tuesday, December 5, 2006 1:28:10 PM Europe/Prague ===== cat: /Users/mkleint/Desktop/test_suite.app/Contents/MacOS/../etc/test_suite.clusters: No such file or directory /Users/mkleint/Desktop/test_suite.app/Contents/MacOS/../platform*/lib/nbexec: /Users/mkleint/Desktop/test_suite.app/Contents/MacOS/../platform*/lib/nbexec: No such file or directory
I looked at the contents of build and varified that the file was indeed there. This quite a high priority for me as my RCP aplication is supposed to run on all Operating Systems and Mac OS X is the only one with problems.
I've check on my linux box and the problem seems to be the zipping of the suite.app folder (which is created by the ant task) doing plain zip -r suite.zip suite.app results in a failing app on macosx. however zip -ry suite.zip suite.app works fine. the -y switch is responsible for preserving symbolic links within the archived content. That seems to do the trick. leaving the bug opened, for consideration if we should od the zip immediatelly in the build script to prevent these kind of errors.
A note could be added after the build or a separate option for setting weather you want to have a zip file or not.
done. included a message describing how to do the final packaging of the .app Unfortunately the ant's zip task cannot be configured to preserve symlinks. Checking in suite.xml; /cvs/apisupport/harness/release/suite.xml,v <-- suite.xml new revision: 1.38; previous revision: 1.37 done