Java no longer installs

VERIFIED FIXED in mozilla0.9


18 years ago
14 years ago


(Reporter: akkzilla, Assigned: samir_bugzilla)




Firefox Tracking Flags

(Not tracked)



(1 attachment)



18 years ago
On commercial linux builds from the past week, Java no longer installs even
though I check the Java box in my custom install.  This is a regression; it
worked up until a week or two ago.  Of course, trying to install after the fact
doesn't work either (that's a longstanding bug) so if you don't get it on
initial install, you're doomed.

On IRC, I was told:
<Fabian> akk : you need to symlink to the plugins dir.. but maybe we should file
a bug saying it doesn't do it automatically
<Fabian> akk : symlink the plugin files in the java2 directory to the moz plugin dir
<Fabian> akk : it seems the plugin is here

Comment 1

18 years ago
I tried going to the directory where netscape was installed
(/usr/local/netscape) and typing:
ln -s plugins/java2/plugin/i386/ns60/ plugins
but no joy, Java still doesn't work.
Severity: normal → major
Keywords: regression

Comment 2

18 years ago
Okay, here's the real command that needs to be executed:
ln -s ../plugins/java2/plugin/i386/ns600/ plugins

Comment 3

18 years ago
reassigning to Samir.
Assignee: ssu → sgehani

Comment 4

18 years ago
Nothing changed in the installer in the timeframe mentioned.  Investigating.
Cci'ing granrose in case build machines moved or we received a new drop of Java.

Comment 5

18 years ago
linux: not me...
commercial: not here...
QA Contact: gemal → gbush

Comment 6

18 years ago
After install ogs on linux I found that although we are executing the
hack, the link to the java plugin is not being created.  On a hunch that this
may be related to the way execute has changed I am cc'ing dbragg and dveditz.

Don, Dan,
I pass in 2 arguments to  This used to work fine before.  Now it
doesn't create the link.  One possibility might be the way the args are
interpreted now.  Need help as to what has changed in this arena.  Else, we can
hack some to do some string parsing if only one argument is passable
now.  This looks like a regression.  Not sure though.

It would help if you could isolate in exactly which trunk build this first
started occuring.  Thanks.

Comment 7

18 years ago
Yes, this info would be very valuable.  I checked in the changes to
nsInstallExcute.cpp on 1/26.

Comment 8

18 years ago
Akkana confirms that manually making the symlink makes java work again.  

Comment 9

18 years ago
I have isolated this base on Don's comments:
The 2001-01-26 8am build creates the symlink, but the 2001-01-26 9pm build
doesn't and Don said his checkin went in on 2000-01-26 after the tree opened on
that day.  Now trying the simple workaround.

Comment 10

18 years ago
Please note that this causes bug 66840. Since this bug is more advanced in its
resolution, should we mark bug 66840 dependant on this one? Or dup?
Keywords: nsbeta1
Priority: -- → P2
Target Milestone: --- → mozilla0.9

Comment 11

18 years ago
I can just confirm that this bug is still valid on Linux Build ID: 2001020808.


Comment 12

18 years ago
Execution on Unix appears totally hosed.  Exectables and shell scripts,
likewise.  Working with Don on this.

Comment 13

18 years ago
We have a solution.  Spun off bug:

Comment 14

18 years ago
Created attachment 24936 [details] [diff] [review]
Explicitly specify that Install.execute() should block.

Comment 15

18 years ago
Please review.

Please super review.

Comment 16

18 years ago
I hate the really complex patch files. <harrrumph>


18 years ago
Whiteboard: Waiting to hear from chofmann/marek if ns trunk is open

Comment 18

18 years ago
Fix checked in.
Last Resolved: 18 years ago
Resolution: --- → FIXED
Whiteboard: Waiting to hear from chofmann/marek if ns trunk is open

Comment 19

18 years ago
Samir, can you please check this into the Mozilla 0.8 branch as well. 

Comment 20

18 years ago
Spoke with Asa.  Clarified that this doesn't need to go into m0.8 since jre.xpi
is only delivered to sweetlou inside netscape on a daily basis.  External users
should not be affected.

Please confirm that the jre.xpi (which is only built in the commercial tree) is
not delivered on a daily basis outside Netscape.  Thanks.

Comment 21

18 years ago
well, the xpi creation should only happen in the script so I leave it
to sgehani to know if that's being generated or not.

However, a find . -name jre.xpi on the mozilla ftp directory does not return any
files so it does not appear to be delivered to the mozilla ftp server.

Comment 22

18 years ago
Thanks Jon.  That confirms that release is not dropping the jre.xpi outside the
firewall so this does not affect m0.8 and mozilla users.

Comment 23

18 years ago
verified on build 2001021306
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.