68039 - Java no longer installs

Status: VERIFIED FIXED

(SeaMonkey :: Installer, defect, P2)

Description

[Akkana Peck]

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
mozilla/plugins/java2/plugin/i386/ns60/libjavaplugin_oji.so

Comment 1

[Akkana Peck]

I tried going to the directory where netscape was installed
(/usr/local/netscape) and typing:
ln -s plugins/java2/plugin/i386/ns60/libjavaplugin_oji.so plugins
but no joy, Java still doesn't work.

Comment 2

[Akkana Peck]

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

Comment 3

[Sean Su]

reassigning to Samir.

Comment 4

[Samir Gehani]

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

[Henrik Gemal]

linux: not me...
commercial: not here...

Comment 6

[Samir Gehani]

After install ogs on linux I found that although we are executing the symlink.sh
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 symlink.sh.  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 symlink.sh some to do some string parsing if only one argument is passable
now.  This looks like a regression.  Not sure though.

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

Comment 7

[dbragg]

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

Comment 8

[Samir Gehani]

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

Comment 9

[Samir Gehani]

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

[Fabian Guisset]

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?

Comment 11

[toor]

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

/Richard

Comment 12

[Samir Gehani]

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

Comment 13

[Samir Gehani]

We have a solution.  Spun off bug:
<http://bugzilla.mozilla.org/show_bug.cgi?id=68356>

Comment 14

[Samir Gehani]

Attachment: Explicitly specify that Install.execute() should block.

Comment 15

[Samir Gehani]

Don,
Please review.

Dan,
Please super review.

Comment 16

[dbragg]

I hate the really complex patch files. <harrrumph>
r=dbragg

Comment 17

[Daniel Veditz [:dveditz]]

sr=dveditz

Comment 18

[Samir Gehani]

Fix checked in.

Comment 19

[Asa Dotzler [:asa]]

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

Comment 20

[Samir Gehani]

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.

Granrose,
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

[Jon Granrose]

well, the xpi creation should only happen in the deliver.pl 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

[Samir Gehani]

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

[Grace Bush]

verified on build 2001021306