Community
Participate
Working Groups
Eclipse 200303062359 RH 8.0 I tried these steps on both windows and linux-gtk. On windows I can launch a debug session, on linux I can not. New workspace Turn of automatic compile Check the plug-ins org.eclipse.ui and all org.eclipse.ui.example.* Select Add Required plug-ins De-select org.apache.xerces (we need this as binary) Say ok to the pop-up Now import org.apache.xerces as binary Now compile. On gtk org.eclipse.jface fails to build because its classpath is incomplete. Cannot find the class file for org.eclipse.swt.internal.gtk.gtkGdkEventKey There is no swt-pi.jar in the directory workspace/org.eclipse.swt.gtk/ws/gtk I only have swt.jar and swt-pisrc.zip In the plug-ins directory I have both swt.jar and swt-pisrc.jar I then copied the swt-pisrc.jar to workspace/org.eclipse.swt.gtk/ws/gtk/. No effect.
Note that the class org.eclipse.swt.internal.gtk.GdkEventKey is in the swt- pi.jar.
Andrew, Could you please clarify the following two steps: >Check the plug-ins org.eclipse.ui and all org.eclipse.ui.example.* >Select Add Required plug-ins Are you importing? Are you checking out from CVS? I thought you were importing using the plug-in import wizard. However, org.eclipse.ui.example.* is not part of the SDK, so I'm not sure what you're doing here. >Say ok to the pop-up Also, what pop-up???
I was able to reproduce the problem by importing org.eclipse.ui and all its dependencies as source. I will fix the problem. However, as a workaround for now, go to the org.eclipse.swt.gtk project and explicity make the the folder 'src-swt-pi' a source folder. Then update the classpath of org.eclipse.jface, and everything should be fine.
The pop-up I referred to says something about not all projects being there, do you want us to do some action. I don't remember the wording, but if you follow the steps I provided I am sure you will see it. I download the examples along with the integration build and install both. I thus see them in the import wizard. What do I update the classpath variable to? Do you not think fixing this is important enough for RC2? If everyone who works with source has to do this, it is going to be quite a pain.
The exact message of the pop-up is: "Some of the required plug-ins cannot be located. Can we resolve them as project references?" Kind of interesting since I asked for all required plug-ins.
Is this a regression? Did it work before? If so, what driver?
I don't understand what you mean by is this a regression. I installed the integration build from this morning, the midnight build. Gave it a brand new workspace and populated from source. I have done this before in the past without issues. Usually I pull the source for the UI from CVS, but I was trying different things this morning. See bug #34133 for what happened when I pulled source from CVS. I have not loaded my workspace from only the import dialog for quite a while, but I do know it worked.
It is a regression. When testing integration builds we usually import all the external plugins and extract source and we have always been able to run eclipse within eclipse in the past.
Note that the org.eclipse.swt.gtk fragment is unique (even for SWT) because it includes a library in its fragment.xml declaration. Most of the SWT frgaments contain the swt.jar but do not reference it in their fragment.xml. GTK is unique for legal reasons.
Dejan, The problem here is not specific to the swt fragment problem. It actually affects importing the source of all runtime libraries whose name is a path of more than one segment: e.g. runtime/gef.jar for the org.eclipse.gef plugin and ws/gtk/swt-pi.jar for the swt.gtk fragment. When we create an entry in the build.properties, we are currently creating an entry: source.gef.jar = src-gef/, while we should instead create source.runtime/gef.jar = src-gef/ Same with the swt.gtk library
Approved for fixing in RC3
Fixed and verified using scenario described in comment #10 (importing org.eclipse.ui and all its dependencies as source). We fixed this problem by creating the source.* key in build.properties using full relative path of the library (not just its last segment). For example, build.properties for the GTK fragment (when imported as source) now has the following entry: source.ws/gtk/swt-pi.jar = swt-pi-src/ Please verify with the next integration build (20030313).
Just tried this on GTK with I200303182359 (RC3), it does not work for the following scenario. 1/ Install Eclipse on GTK 2/ With new workspace, import plug-ins and fragments for org.eclipse.ui plus all required plug-ins. 3/ Note that org.eclipse.jface can not build due to the classpath problem: "Cannot find the class file for org.eclipse.swt.internal.gtk.gtkGdkEventKey" Tried a rebuild all, no effect.
Fixed. Problem was due to the fact that we clear the classpaths of projects being imported in the first phase of the import operation.
I20030319
Tried the following on I200303272130 (RC4?) Turn off auto-compile From CVS load platform-core, platform-ui and platform-ui-examples Import as source all required plug-ins for these packages jface fails to compile due to incomplete class-path.
First, the solution: update the classpath of org.eclipse.jface explicitly using PDE's update classpath utility and everything will work fine. Second, the explanation: The problem is that the .classpath file that you checked out along with the org.eclipse.jface project from CVS is incomplete in a gtk scenario. That .classpath only contains references to the org.eclipse.swt plug-in. On gtk, for jface to compile, the classpath needs to also reference org.eclipse.swt.gtk, *if this fragment contains source* in your workspace, which is the case here. This is where PDE comes in. When you update the classpath using PDE, PDE will check to see if org.eclipse.swt.gtk has source and will add it to org.eclipse.jface's classpath if it does. Everything then compiles fine. Note that if you had imported org.eclipse.jface with source using PDE's import instead of checking it out from the repository, the classpath would have been computed correctly by PDE right off the bat.
Can you explain why jface would require a reference to the org.eclipse.swt.gtk swt-pi.jar? This jar contains only internal classes, to be more specific, it contains only those internal classes which define the JNI required to call the operating system calls. I can guarantee that jface never calls any of the API in this jar. So why does the jface classpath need to reference it? Why is this different from how Windows works? I am reopening this bug report. Although there is a workaround, the default functionality is still incorrect.
I selected the plugin-xml for org.eclipse.jface, and choose the Update Classpath menu item. It corrected the problem as indicated.
According to the JDT compiler, org.eclipse.jface.wizard.ProgressMonitorPart indirectly references the type 'org.eclipse.swt.internal.gtk.GdkEventKey' and that is why org.eclipse.jface cannot compile without adding the swt.gtk fragment directly to the classpath. This is definitely not PDE domain. I'm not sure what functionality of PDE is incorrect in Veronika's view. Andrew checked out org.eclipse.jface from the repository with its .classpath (PDE is not involved at this step). He then imported org.eclipse.swt and its fragment using PDE's wizard, and the org.eclipse.jface's classpath (which PDE did NOT compute) was insufficient for compilation. If anything, PDE actually can rescue such situations by updating the classpath of projects checked out from the repository.
Adding Phillipe to the discussion to understand why "According to the JDT compiler, org.eclipse.jface.wizard.ProgressMonitorPart indirectly references the type 'org.eclipse.swt.internal.gtk.GdkEventKey' and that is why org.eclipse.jface cannot compile without adding the swt.gtk fragment directly to the classpath." ProgressMonitorPart only calls API that is defined in swt.jar. The fact that swt.jar relies on API defined in swt-pi.jar should not require that ProgressMonitorPart also reference swt-pi.jar. ProgressMonitorPart is no different from any other class that uses the SWT API so I do not see why it is requiring special treatment.
Kent - pls investigate. It could be that indirectly some supertype is referring to some private implementation (on a method/field signature) and thus dragging internal components. Isn't this the case ?
Compile errors are explainable due to the classpath being incomplete. Note swt.gtk and core.boot are added: Classpath before update (with compile errors) <?xml version="1.0" encoding="UTF-8"?> <classpath> <classpathentry kind="src" path="src"/> <classpathentry kind="src" path="/org.apache.xerces"/> <classpathentry exported="true" kind="src" path="/org.eclipse.swt"/> <classpathentry kind="var" path="JRE_LIB" sourcepath="JRE_SRC"/> <classpathentry kind="src" path="/org.eclipse.core.runtime"/> <classpathentry kind="output" path="bin"/> </classpath> Classpath after update <?xml version="1.0" encoding="UTF-8"?> <classpath> <classpathentry kind="src" path="src/"/> <classpathentry kind="src" path="/org.apache.xerces"/> <classpathentry exported="true" kind="src" path="/org.eclipse.swt"/> <classpathentry exported="true" kind="src" path="/org.eclipse.swt.gtk"/> <classpathentry kind="src" path="/org.eclipse.core.runtime"/> <classpathentry kind="src" path="/org.eclipse.core.boot"/> <classpathentry kind="con" path="org.eclipse.jdt.launching.JRE_CONTAINER"/> <classpathentry kind="output" path="bin"/> </classpath>
The super class of ProgressMonitorPart is a Composite which is an SWT widget and therefore is quite likely to call internal stuff in swt-pi.jar. So why does the classpath of ProgressMonitor part need to include the stuff its super class references?
Moving to JDT core as they investigate.
Kent - is this a case where we could be more lazy when verifying inherited method signatures ?
Veronika: Can you reproduce any of these scenarios on the latest build?
Retried sceanrios with 3.0 I20031113 build and did not get the errors.
