Description of problem:
Trying to open php files in eclipse using the php-eclipse plugin reports an
error asking the user to look at the log file
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Start eclipse
2. Open a php file
Error report is spat out requesting the user look at the log file for more
information, incidently phpeclipse does not inform the user where the log file
is. Log file is attached.
The file to open
I have uninstalled, reinstalled, and wiped out my projects, all my local eclipse
configuration no less than 5 times trying to get eclipse to actually install
properly, eventually I managed to get a workspace to load. Then after getting a
workspace to load still not actually being able to use it. These problems with
the eclipse install, and eclipses inability to gracefully handle errors (with
.metadata folders) have persisted since fedora core 5. As a result I have made
the decision today to switch to using ubuntu, after being a loyal redhat user
Created attachment 148901 [details]
eclipse log file
Reassigning to component owner.
I am unable to reproduce this error on both x86_64 and i386. I have yum erased
eclipse-* and installed the versions you mentioned, also starting with a brand
new workspace and starting a brand new project and creating a brand new PHP
file. In all cases on the 3 computers I tried, the editor opens fine and I can
edit and save and close and open my PHP files all day.
What is listed in your Help > Software Updates > Manage Configuration
Can you reproduce this on another machine (preferably one with a fresh FC6
install) ? If so, can you help me reproduce the crash?
Can you create a method of cleaning my machine of all eclipse configuration and
stray metadata folders and all the rest of the nonsense that I must be missing?
I have another problem on my other FC6 machine where the workspace won't even
open. Nothing but problems eclipse has been since FC5 when I had phpeclipse,
pydev and my cdt working perfectly!
I will help you debug the issue if you can figure out a reasonably sensible way
to proceed. Baring in mind that I cannot fresh install.
I have just removed;
and moved ~/workspace to ~/workspace.old
[root@localhost klattimer]# find . -name .metadata
I've also openened another bug while trying to sort this issue out #230528
Created attachment 149009 [details]
A second eclipse log problem
A second eclipse log problem
After uninstalling and reinstalling eclipse again i now get this error before
the workbench actually starts.
I currently have the following eclipse RPMs installed
I'm betting that one of the dependencies isn't included in the packages.
Incidentally comment #4 I removed those folders AFTER uninstalling the RPMS via
Appears the last problem was related to a stale CVS install of the phpeclipse
plugin. I have since removed that and am yet again re-installing eclipse and
Created attachment 149012 [details]
yet another log file
After discovering stale files in /usr/lib/eclipse and /usr/lib64/eclipse and
removing them as well as all other folders/files associated with eclipse I could
find I have provided yet another log file.
Does anyone actually know how to decifer the important parts from these logs?
These seem important,
java.lang.RuntimeException: No application id has been found.
!MESSAGE Missing required bundle org.eclipse.swt_[3.2.0,4.0.0).
I have now re-installed libswt3-gtk2 i386 and x86_64 my workbench now starts
again, and I can now open php files.
It appears any stale files left over in lib/eclipse cause this issue. It has
been a rediculous situation trying to trace this problem as very little
understandable information is put out in the eclipse log file, some HUMAN
readable errors would be nice.
The ability for eclipse to actually sense a problem and avoid it would also be nice.
Am I asking the earth to have eclipse work sensibly?
Thanks for your help, although I eventually solved it on my own, please make
future phpeclipse releases remove all stale files (even those installed via the
update manager) from the system thereby preventing this issue re-occurring.