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

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.

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

reassigning to Samir.

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.

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

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.

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

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

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.

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?

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

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

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

Don, Please review. Dan, Please super review.

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

sr=dveditz

Fix checked in.

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

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.

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.

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.

verified on build 2001021306