Bug 1000740

Looks like the symlinks for these packages were updated to the latest packaging guidelines (use XMvn) and as a result the jar names have changed. This will require small modifications in %%{SOURCE1) at org.eclipse.linuxtools.eclipse-build/dependencies/replace_platform_plugins_with_symlinks.sh . There's some other things I need to do but hopefully I'll have a chance to get to this as well.

I was thinking it might be easier to create compatibility symlinks in the updated packages given that there may be more packages that switch over to XMvn which are likely to result in slightly different jar locations. Either way I've pushed a build http://koji.fedoraproject.org/koji/taskinfo?taskID=5862471 . Let me know if this fixes the issue.

(In reply to Roland Grunberg from comment #2)
> I was thinking it might be easier to create compatibility symlinks in the
> updated packages given that there may be more packages that switch over to
> XMvn which are likely to result in slightly different jar locations.

Easier, maybe. I think it would be cleaner to find and fix all the references though, otherwise we may end up with lots of compatibility links all over the place.

> Either way I've pushed a build
> http://koji.fedoraproject.org/koji/taskinfo?taskID=5862471 . Let me know if
> this fixes the issue.

Almost! :) I've found two more references that need to be updated in /usr/lib64/eclipse/dropins/jdt/plugins/ 

I've fixed those links in a local mock env, and everything appears to work fine after that, so updating them in rawhide/f21 should fix all the things.

Thanks!

(In reply to Gerard Ryan from comment #3)
> Almost! :) I've found two more references that need to be updated in
> /usr/lib64/eclipse/dropins/jdt/plugins/ 

By the by, it's the same two jars that are linked in here that are broken too. i.e.:
javax.servlet.jsp_2.2.1.jar
org.apache.felix.gogo.runtime_0.10.0.jar

The only symlinks I see in that folder are :

junit.jar -> /usr/share/java/junit.jar
org.hamcrest.core_1.3.0.v201303031735.jar -> /usr/share/java/hamcrest/core.jar

The latest versions on rawhide (hamcrest-1.3-5.fc20, junit-4.11-7.fc21) both use those paths.

I'm basically testing this on rawhide by doing a 'mock -r fedora-rawhide-i386 --install eclipse-jdt' and confirming that the packages mentioned have symlinks and are the latest version. Can you confirm that the latest version of Eclipse was grabbed by your mock environment ?

As we discussed in IRC, it was in release -11.1 that I saw those strange symlinks. All is working now, thanks.

I'll leave it to you to close this bug, in case you would like to use it to track why the strange symlinks ended up in dropins/jdt/plugins/

So the problem seems to be happening because of a small bug in 'replace_platform_plugins_with_symlinks.sh' and the error gets compounded in 'move_JDT_PDE_to_dropins.sh'.

The '_symlink' function in 'replace_platform_plugins_with_symlinks.sh' assumes the file must exist (either in SCL_JAVA_DIR or /usr/share/java). If the file doesn't exist this will create a broken symlink in /usr/share/java. (The koji build logs also confirm this is happening : http://kojipkgs.fedoraproject.org//packages/eclipse/4.3.0/11.fc20/data/logs/i686/build.log )

After this, 'move_JDT_PDE_to_dropins.sh' attempts to determine what is part of the JDT and what is part of PDE. To do this it takes a basic eclipse installation, makes a duplicate, and installs a specific feature (eg. -installIU org.eclipse.jdt.feature.group). Now the dropins location will receive every bundle that is in the new installation, but not in the old one. (eg. jdt dropins = (platform + jdt) - (platform)). The problem is that the files in the new installation are listed with 'ls' and their existence is checked with [ -e  $file ]. A symlink will get listed, but it doesn't actually exist so it becomes part of that particular dropins location.

I've fixed this upstream with http://git.eclipse.org/c/linuxtools/org.eclipse.linuxtools.eclipse-build.git/commit/?id=fd2b404fed299a1f2af8c183d86c0cfc4bfc63e9 . A non-existent target for a symlink should fail the build rather than create a potentially broken one. This will eventually end up in Fedora eventually.

I'm going to close this as RAWHIDE given that the problem is resolved for now on rawhide. If more broken symlinks are found as dependent packages get updated, feel free to reopen this bug.