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.

Bug 46566

Summary: Mobility addon installer - Browse button does not work
Product: installer Reporter: sigalduek <sigalduek>
Component: CodeAssignee: mslama <mslama>
Severity: blocker CC: jchalupa, mryzl, non_migrated_user, pkeegan
Priority: P2 Keywords: RELNOTE
Version: 4.x   
Hardware: All   
OS: All   
Issue Type: DEFECT Exception Reporter:
Bug Depends on:    
Bug Blocks: 42864    
Attachments: install log

Description sigalduek 2004-07-26 14:29:50 UTC
When working with mobility add-on installer  and
use windows xp and java 1.4.2_02, when I press on
the Browse button - it does nothing (the
filechooser does not open).
Comment 1 mslama 2004-07-27 11:37:57 UTC
It works for me Win XP, JDK 1.4.2_05. Please try again. I saw the same
with NB installer on JDK 1.5.0 beta 3 but after while it started to
work again. (You can use -is:javahome <JDK location
eg.:"C:\j2sdk1.4.2_05"> command line switch to select JDK used to run
Comment 2 Martin Ryzl 2004-08-10 17:32:39 UTC
It doesn't work with JDK 1.5 Beta2 - b51. As far as I know it will be
latest available JDK 1.5 at the date of releasing NB 4.0 Beta and it
means that users will discover highly visible bug when installing
Mobility add-on. Therefore I don't agree with WORKSFORME evaluation
and reopening the bug.
Comment 3 _ ttran 2004-08-10 20:29:35 UTC
mryzl, what do you suggest?  This is a bug in JDK beta, we can't fix
it on our side.  

The only thing I can think of is add a note to the installation guide
which should be linked directly from the download page.

Note this is not a hard showstopper, the user can manually type in the
path.  Bad out of the box experience?  Yes
Comment 4 mslama 2004-08-13 10:29:31 UTC
One possibility could be to bundle JVM (eg.JRE 1.4.2) with windows
installer. (It will bypass installed JDK 1.5.0 beta2 for running
installer.) Disadvantage is additional 10MB for Windows installer and
also longer startup of installer. So the question is if it is acceptable.
Comment 5 Patrick Keegan 2004-08-13 11:01:21 UTC
Anatole, I'm adding you to the CC so that you can keep up to date on
this for possible release noting
Comment 6 Martin Ryzl 2004-08-13 11:07:27 UTC
is there a way how to tell installshield to prefer jdk1.4.x over jdk1.5?
So far the biggest problems is on Windows where, I assume, most people
will have jdk1.4.x and jdk 1.5 beta2 installed. So far IS prefers
jdk1.5. If jdk1.4 would be prefered runtime for IS and 1.5 as a
runtime for IDE it would at l
Comment 7 Martin Ryzl 2004-08-13 11:13:29 UTC
and one more comment: this problems should be present even in netbeans
installer (I haven't verified it yet because I have to reinstall
jdk1.5) so it should be documented in NetBeans IDE relnotes as well.
However, NetBeans installer suggests installation directory and most
users just click on next button. So another "workaround" would be to
suggest mobility users the same directory (if it contains netbeans
installation, of course).
Comment 8 mslama 2004-08-13 11:26:43 UTC
Yes. JVM resolution for installer can be set to look for JDK 1.4.X
first so if both JDKs are installed 1.4.x will be used. (At least on
Linux and Solaris. I have to check on Windows.) Anyway -is:javahome
command line option can be used to set desired JVM for installer. I
will check order of JVM resolution.
Comment 9 mslama 2004-08-13 12:13:17 UTC
Done. JDK 1.4.2_X is searched first then JDK 1.5.0_X or JDK 1.5.1.
(There is hint file where possible paths are defined.) You can check
what native launcher does with command line option "-is:log <log file
Comment 10 _ ttran 2004-08-13 12:58:46 UTC
Marek, I assume you did it for trunk only.

Folks, we should consider putting it in beta1 branch
Comment 11 mslama 2004-08-13 13:04:27 UTC
Yes in trunk only. Let me know today till 5pm if I should put this
change to beta branch. (I also added path hints for win JVM resolution
1.4.2_05,...._08 for future.)
Comment 12 _ ttran 2004-08-13 13:05:38 UTC
did you verify if it works on windows?
Comment 13 mslama 2004-08-13 13:31:52 UTC
I tested on Windows XP that it searches for JDK 1.4.2 first.
Comment 14 _ ttran 2004-08-13 13:35:14 UTC
take the risk, put it in the beta1 branch please.

Comment 15 Petr Blaha 2004-08-13 13:42:18 UTC
I will test JVM resolution on other Win boxes.
Comment 16 mslama 2004-08-13 14:09:36 UTC
I tested again on Windows XP. Both JDK 1.4.2_05 and JDK 1.5.0 build 62
are installed. Log from native launcher says that JDK 1.4.2_05 is
found and used to run installer.

I also enabled console logging in beta1 branch. (First change of
coreide.xml and cluster.xml files. Then it is possible to use command
line switch "-is:javaconsole" for native installer to get some log
from installer.)

Modified (branch QBE200408101800):
/cvs/installer/coreide/coreide.xml 1.4 -> ->
/cvs/installer/coreide/resources/jdk14Xwin32.jvm 1.1 ->

/cvs/installer/cluster/cluster.xml 1.3 -> ->
/cvs/installer/cluster/resources/jdk14Xwin32.jvm 1.1 ->

Comment 17 sigalduek 2004-08-15 10:00:42 UTC
Still does not work on my configuration.
Windows XP Professional, jsk 1.5 beta2 (build 1.5.0-beta2-b51).
I have jsk 1.4.2_02 installed on my machine((build 1.4.2_02-b03, mixed
Comment 18 mslama 2004-08-16 08:59:37 UTC
Try -is:log <logfile name> (eg. -is:log installer.log) and attach it
here. It will log what native lancher does ie. how JDK is searched for.
Comment 19 Petr Blaha 2004-08-16 10:17:33 UTC
JDK resolution doesn't work on my machine too (Win 2000). I have
installed j2dsk1.4.2_04 and jdk 1.5.0. Installer used JDK 1.5. See
installer's log.
Comment 20 Petr Blaha 2004-08-16 10:18:13 UTC
Created attachment 16831 [details]
install log
Comment 21 mslama 2004-08-16 10:40:27 UTC
You have still previous version of installer (JDK 1.5 is searched
first.). I changed it on Friday. What installer do you use?
Comment 22 Petr Blaha 2004-08-16 13:06:44 UTC
Sorry, I had old installer. It's working in the latest pre-beta Build
Comment 23 mslama 2004-08-31 12:34:28 UTC
*** Issue 48187 has been marked as a duplicate of this issue. ***