Bug 1264099

here are the details to reproduce the error:


Attached zip dummyProductAndPlugin.zip need to be imported into Eclipse:
Start Eclipse, go to File -> Import -> Existing Projects into Workspace -> Select archive file -> Browse... -> /path/to/dummyProductAndPlugin.zip -> OK

One will see two projects selected, now say "Finish".

Back to File menu, select Export -> Plugin Development -> Eclipse Product -> Configuration -> Browse ... -> dummyProductExport -> dummyProductExport.product -> OK.
Root directory: eclipse
Destination: archive file -> /tmp/test.zip
Export options: all checked (see attachment if unclear).
Now press "Finish".
An error will be shown to the user and one additionally logged to the error log (open Error Log view to see it). Attached pictures show errors.

We don't ship Eclipse in base RHEL 7 (though we do in the Red Hat Developer Toolset), and according to 'eclipse.buildid=20130131-0800', this would seem to be Eclipse 3.8.2 (Juno), so this is very likely an Eclipse instance downloaded from upstream (eg. http://archive.eclipse.org/eclipse/downloads/drops/R-3.8.2-201301310800/download.php?dropFile=eclipse-SDK-3.8.2-linux-gtk-x86_64.tar.gz).

We don't really have a way of delivering a fix for the user from the Eclipse side, but I am able to reproduce the error, and removing the broken symlink does resolve the issue. If this path is chosen, the bug component should be changed to 'java-1.7.0-opendjk'.

As an alternative, I also noticed that the error doesn't happen at all on Eclipse Kepler SR2 (4.3.2), likely because the jre folder of the jvm isn't copied into the generated product, so we could ask the user if upgrading their Eclipse to 4.3.2 or later is a possibility.

I've initiated this bug report and yes, please change the bug component to 'java-1.7.0-opendjk', since we are not yet on 1.8 java and the transition could take time. The bug must be fixed by removing (or fixing) the broken symlink.
Please also verify if the same issue appears on java-1.8.0-opendjk too.

(In reply to comment #3)
> Please also verify if the same issue appears on java-1.8.0-opendjk too.

Yes, the same issue exists for java-1.8.0-openjdk-headless-1.8.0.31-2.b13.el7.x86_64 : 'java.io.FileNotFoundException: /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.31-2.b13.el7.x86_64/jre/lib/audio/default.sf2 (No such file or directory)'

The soundfont package is an optional dependency of OpenJDK. We do not pull it in because it default.sf2 is provided by fluid-soundfont-gm, which is a 120MB package.

Since RPM has concept of optional dependencies, we have to keep the broken link, and the customer can install the soundfont file if needed.

This sounds like an issue that would have to be worked around in Eclipse (if the customer is not open to manually installing the soundfont package).

Roland, WDYT?

(In reply to Deepak Bhole from comment #5)

> Since RPM has concept of optional dependencies, we have to keep the broken

s/has concept/has no concept

It looks like the symlink has been around for a while (Bug 541466, Bug 1079668). Was it never considered to have soundfont contribute the symlink (rather than java-openjdk) or is there an issue with that ?

Andrey, Is installing fluid-soundfont-gm a possibility ? We don't ship any version of Eclipse in the base RHEL 7. If you're using Eclipse 3.8.2 (eclipse.buildid=20130131-0800) then this would be an issue that the Eclipse PDE project needs to resolve, if they're still supporting 3.8.2. I really don't think this is the case though, so the only other alternative I can think of is to update to at least Eclipse Kepler (4.3.2) from eclipse.org, or from the Red Hat Developer Toolset (which would be supported).

(In reply to Roland Grunberg from comment #7)
> It looks like the symlink has been around for a while (Bug 541466, Bug
> 1079668). Was it never considered to have soundfont contribute the symlink
> (rather than java-openjdk) or is there an issue with that ?
> 

Unfortunately that would not be possible as the JDK installation directory contains the NVRA (and thus differs each time) due to the multi-jdk-install feature that was requested for RHEL-7.

> Andrey, Is installing fluid-soundfont-gm a possibility ? We don't ship any
> version of Eclipse in the base RHEL 7. If you're using Eclipse 3.8.2
> (eclipse.buildid=20130131-0800) then this would be an issue that the Eclipse
> PDE project needs to resolve, if they're still supporting 3.8.2. I really
> don't think this is the case though, so the only other alternative I can
> think of is to update to at least Eclipse Kepler (4.3.2) from eclipse.org,
> or from the Red Hat Developer Toolset (which would be supported).

+1 to this -- if the customer can install the font file, that would be best.

(In reply to Roland Grunberg from comment #7)
> Andrey, Is installing fluid-soundfont-gm a possibility ? 

According to my Linux admin there is no such rpm for RHEL7 :-(

Sorry about that. I didn't even consider to check if it was there (just assumed it was) -- you are right, I don't see it in RHN either :(

Adding the JDK packager and Java QE lead to cc:

Jiri, fluid-soundfont is not shipped in RHEL-7, yet the OpenJDK package contains a broken symlink to it. Can you please look into it and remove the symlink if appropriate? We can bundle the change into the October CPU update.

Also, we should add tests to check for broken symlinks so that something like this is caught in the future.

But that dangling symlink do not hurt at all. It will become just another line with needed comment why the specfile is different from Fedora or Older rhels. 
If Eclipse is failing becasue of dangling symlink, then it is error in Eclipse. 

I have check for dangling symlinks, but this is exception. It is broken in purpose[1] and for pretty long time[1]. If somebody install soundfont, then it magically starts to work.  Same approach is taken for example for awt bridge (but here the link is not in main package)

[1] https://bugzilla.redhat.com/show_bug.cgi?id=541466

I'm really a lot for keeping link in JDK and fixing this in eclipse.

(In reply to Roland Grunberg from comment #7)
> It looks like the symlink has been around for a while (Bug 541466, Bug
> 1079668). Was it never considered to have soundfont contribute the symlink
> (rather than java-openjdk) or is there an issue with that ?
> 

Soundfont package can not own file in directory tree owned by openjdk.

The java works fine when the target of the link is supplied by any file...

Still, I insists its bug in eclipse and above is just workaround.

(In reply to jiri vanek from comment #13)
> The java works fine when the target of the link is supplied by any file...
> 

There is nothing in RHEL-7 that supplies that target though...

> Still, I insists its bug in eclipse and above is just workaround.

I don't see a fluid-soundfont package in EPEL either.

I agree that we should remove the dangling symlink if it can not ever work. My opinion would probably be different if there was an EPEL package or some other way for users to get this soundfont package. But, as it is, this symlink provides no features.

(In reply to jiri vanek from comment #11)
> It will become just another
> line with needed comment why the specfile is different from Fedora or Older
> rhels.

Perhaps you can use an explicit spec file conditional like:

%if 0%{rhel} > 6
  # comment explaining why this is needed
  # rm the dangling symlink
%endif

To make this change safe to merge everywhere?

Another option would be to modify OpenJDK to try and read the file that the symlink points to directly. That would avoid the need for that symlink completely (across distributions) but still allow the code to work if the file that the symlink points to is available.

Hello, as upstream patch is in progress, I will remove this dangling symlink from rhel 7  in both openjdk 7 and openjdk8

This is already fixed. co ACK to have it properly QAcked.