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.
I've tried this with both jdk 1.5 beta2 and rc1 (amd64 version) and netbeans beta1, the latest q-build and daily build (as of today). When I install netbeans everything works fine except for when I try to start netbeans with the icon the installer places on my desktop it gives an error that the file can't be executed. I discovered these 2 files {INSTALL DIR}/bin/netbeans {INSTALL DIR}/platform4/lib/nbexec have a mode of 644 which keeps netbeans from starting correctly. When i change the mode to executable for both files, then netbeans starts perfectly. My Machine Specs: AMD64 3200+ Gentoo compiled for AMD64 Linux Kernel 2.6.8-r3
On Linux Fedora Code 2 I have after installation this file in NBINSTALLDIR/bin directory: -rwxr-xr-x 1 mslama users 2412 Sep 27 13:19 netbeans It is executable for user. If I am right it corresponds to mode 755. I have no idea why it is set differently at your system. Installer is set to keep file permissions. If it will persist and will happen to more users I can try to set explicitely execute permission for file "netbeans" in installer.
Are you using AMD64 Version of Fedora and JDK? I don't have this problem on any x86 machines, only my x86_64.
No we do not have AMD64 machine now available.
I just tested on our testing machine (both on NFS and local disk) and permissions are not correct when using: java version "1.5.0" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0-b64) Java HotSpot(TM) 64-Bit Server VM (build 1.5.0-b64, mixed mode) It is OK when using Linux JDK: java version "1.5.0" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0-b64) Java HotSpot(TM) Server VM (build 1.5.0-b64, mixed mode) So workaround is to use Linux JDK for running installer. We have no special code for AMD64 JDK in NB installer. In our InstallShield project we set to preserve existing file attributes. Not sure where problem is if JDK or InstallShield.
It looks like problem of InstallShield on 64bit Java. I created simple installer with just one file to install with exec permission and it si also lost. The problem is that there are not only mentioned 2 files but also more scripts in tomcat and possibly even more. So I do not think that explicitely set exec permission as workaround is good solution as we can find new files which need to set this flag. I will report this to InstallShield.
It works correctly with InstallShield X SP2 - exec permission is not lost. One reason to upgrade our installer from IS MP5 to IS X. I tested both with simple example installer and with NetBeans installer built with IS X. I will keep this opened and close as we move to IS X. Workaround is to use zip and simply unzip it to desired location or run installer with 32bit Linux Java.
I just found that when running installer on 64bit Linux + AMD 64 + 64bit JDK (Linux 2.4.21-20.ELsmp #1 SMP Wed Sep 15 20:03:51 EDT 2004 x86_64 x86_64 x86_64 GNU/Linux) InstallShield does not detect Linux as it does with 32bit JDK on the same OS/machine but it detects Generic UNIX. I also found that os.arch returned by 64bit JDK is amd64 but 32bit JDK returns i386. When I add platform support for Generic UNIX NB installer works also on 64bit JDK.
We can still use installer build for Linux. It runs OK. (ie. we do not need to build another installer distribution for Generix UNIX.) I had to add platform support for Generic UNIX so that changing file permissions and checking if current user is admin works correctly. Installer generates uninstaller for Generic UNIX when run on 64bit JDK instead of Linux uninstaller as when run on 32bit JDK. So uninstaller for Generic UNIX must be configured with JVM resolution. Still if I run installer on 32bit JDK and uninstaller on 64bit JDK it works fine. ie. Linux uninstaller works fine with 64bit JDK. I also found that path hints with double quotes does not work for Generic UNIX uninstaller so I removed double quotes from path hints. It still works for Linux/Solaris so I did not split JVM resolution files to Linux/Solaris and Generic UNIX. Fix of JVM resolution files (shared): /cvs/installer/lib/resources/jdk14Xunix.jvm new revision: 1.4; previous revision: 1.3 /cvs/installer/lib/resources/jdk15Xunix.jvm new revision: 1.3; previous revision: 1.2 /cvs/installer/lib/resources/jdk16Xunix.jvm new revision: 1.2; previous revision: 1.1 Fix of NetBeans installer project: /cvs/installer/coreide/coreide.xml new revision: 1.28; previous revision: 1.27
Fixed for asbundle installer: /cvs/installer/asbundle/as-linux.xml new revision: 1.17; previous revision: 1.16
Fixed in j2ee project: /cvs/installer/j2ee/j2ee.xml new revision: 1.8; previous revision: 1.7
Marek, could this be backported for the 4.1 installers? I think we should do it.
I was talking about that with Marek and we agreed that it's a little bit risky to add in NetBeans 4.1. I recommend to fix it only in trunk.
I would prefer not to backport it to NB 4.1. There is simple workaround: Use 32bit JDK to run installer. In addition we have so far only 2 reports so I assume there is not many users who are using only 64bit JDK.
Ok, agreed.
Fixed in mobility installer: /cvs/installer/mobility/mobility.xml new revision: 1.7; previous revision: 1.6
Fixed for profiler installer (both main trunk and release40 branch as profiler will be provided for NB 4.0): /cvs/installer/profiler/profiler-linux.xml new revision: 1.5; previous revision: 1.4 "release40": /cvs/installer/profiler/profiler-linux.xml new revision: 1.2.2.4; previous revision: 1.2.2.3 Tested with JDK 1.5.0_02 64bit for AMD64.
Issue has been verified in the latest 4.2 build #200504131800 in trunk under RH EL3 and 64bit JDK1.5.0_01 running on AMD Opteron
*** Issue 58213 has been marked as a duplicate of this issue. ***
*** Issue 58844 has been marked as a duplicate of this issue. ***