Community
Participate
Working Groups
In our eclipse-projects we have a linked classfolder that contains sources from other subsystems, which should not get compiled automatically. This classfolder lies outside the original project location. If these linked java-sources are browsed, the outline and the editor seem to work right in the first look. But when a method or member is selected in the outline, the editor does not jump to the specified position in the source. This problem only occurs with linked classfolders, not with "common" jar-libraries. As clarification I append the contents of .project and .classpath <B>.project</B> <?xml version="1.0" encoding="UTF-8"?> <projectDescription> <name>techquer-TEQ_2.0.0_bno</name> <comment></comment> <projects> <project>techquer-TEQ_2.0.0_co</project> </projects> <buildSpec> <buildCommand> <name>org.eclipse.jdt.core.javabuilder</name> <arguments> </arguments> </buildCommand> </buildSpec> <natures> <nature>org.eclipse.jdt.core.javanature</nature> </natures> <linkedResources> <link> <name>cl</name> <type>2</type> <location>D:/fdv/w_7.0.x/techquer-TEQ_2.0.0/techquer/src/cl</location> </link> </linkedResources> </projectDescription> <B>.classpath</B> <?xml version="1.0" encoding="UTF-8"?> <classpath> <classpathentry kind="src" path="/techquer-TEQ_2.0.0_co"/> <classpathentry kind="lib" path="cl"/> <classpathentry excluding="cl/" kind="src" path=""/> <classpathentry kind="lib" path="C:/SEU/xalan210/bin/xerces.jar" rootpath="" sourcepath=""/> <classpathentry kind="lib" path="C:/SEU/xalan210/bin/bsf.jar" rootpath="" sourcepath=""/> <classpathentry kind="lib" path="C:/SEU/xalan210/bin/xalan.jar" rootpath="" sourcepath=""/> <classpathentry kind="lib" path="C:/SEU/Fop0202/build/fop.jar" rootpath="" sourcepath=""/> <classpathentry kind="lib" path="C:/SEU/Fop0202/lib/batik.jar" rootpath="" sourcepath=""/> <classpathentry kind="lib" path="C:/SEU/Fop0202/lib/jimi-1.0.jar" rootpath="" sourcepath=""/> <classpathentry kind="lib" path="C:/SEU/Fop0202/lib/avalon-framework-4.0.jar" rootpath="" sourcepath=""/> <classpathentry kind="lib" path="C:/SEU/Fop0202/lib/logkit-1.0b4.jar" rootpath="" sourcepath=""/> <classpathentry kind="lib" path="C:/SEU/regexp11/regexp11.jar" rootpath="" sourcepath=""/> <classpathentry kind="lib" path="C:/SEU/oro206/jakarta-oro-2.0.6.jar" rootpath="" sourcepath=""/> <classpathentry kind="lib" path="C:/SEU/acrobat20001202/acrobat.zip" rootpath="" sourcepath=""/> <classpathentry kind="lib" path="C:/SEU/acrobat20001202/MRJToolkitStubs.zip" rootpath="" sourcepath=""/> <classpathentry kind="lib" path="C:/SEU/StarOffice6.0/program/classes/juh.jar" rootpath="" sourcepath=""/> <classpathentry kind="lib" path="C:/SEU/StarOffice6.0/program/classes/jut.jar" rootpath="" sourcepath=""/> <classpathentry kind="lib" path="C:/SEU/StarOffice6.0/program/classes/jurt.jar" rootpath="" sourcepath=""/> <classpathentry kind="lib" path="C:/SEU/StarOffice6.0/program/classes/ridl.jar" rootpath="" sourcepath=""/> <classpathentry kind="lib" path="C:/SEU/StarOffice6.0/program/classes/sandbox.jar" rootpath="" sourcepath=""/> <classpathentry kind="lib" path="C:/SEU/StarOffice6.0/program/classes/unoil.jar" rootpath="" sourcepath=""/> <classpathentry kind="lib" path="C:/SEU/StarOffice6.0/program/classes/java_uno.jar" rootpath="" sourcepath=""/> <classpathentry kind="lib" path="C:/SEU/log4j113/dist/lib/log4j.jar" rootpath="" sourcepath=""/> <classpathentry kind="lib" path="C:/SEU/jdk131/jre/lib/rt.jar" rootpath="src" sourcepath="c:/seu/jdk131/src.jar"/> <classpathentry kind="lib" path="C:/SEU/jdk131/lib/tools.jar" rootpath="" sourcepath=""/> <classpathentry kind="lib" path="C:/SEU/jhelp111/jhall.jar" rootpath="" sourcepath=""/> <classpathentry kind="lib" path="C:/SEU/jhelp111/jhtools.jar" rootpath="" sourcepath=""/> <classpathentry kind="lib" path="C:/SEU/jhelp111/jsearch.jar" rootpath="" sourcepath=""/> <classpathentry kind="lib" path="C:/SEU/oc4j90200/j2ee/home/ejb.jar" rootpath="" sourcepath=""/> <classpathentry kind="lib" path="C:/SEU/oc4j90200/j2ee/home/oc4jclient.jar" rootpath="" sourcepath=""/> <classpathentry kind="lib" path="C:/SEU/_tools/junit37/junit.jar" rootpath="" sourcepath=""/> <classpathentry kind="lib" path="C:/SEU/_tools/xmlunit/lib/xmlunit0.8.jar" rootpath="" sourcepath=""/> <classpathentry kind="lib" path="C:/SEU/_tools/jemmy20/jemmy.zip" rootpath="" sourcepath=""/> <classpathentry kind="output" path=""/> </classpath>
Your project layout looks really suspicious. I am not sure it is doing what you would like it to do. Could you please try to tell me what you are trying to do? Why do you use a class folder to contain source files? These source files will never be compiled. I tried to do that and I had to go to the navigator to open the source file inside this classfolder. Then I had no problem to select an element in the outliner and see the corresponding element selected in the editor. So for now your problem is completely obscure. Could you please provide a simple test case that doesn't work? But first of all, try to explain the layout that you use.
Hi, ok, its a bit complicated to explain this, because our project structure seems highly unusual. We are working on a grand scale project (about 5000 EJBs, some hundred thousend classes). This project is seperated into many (about 30) subsystems. So one developer works usually on a single subsystem but uses the subsystems that are produced by other developers (subsystems buid a dependency tree, not circular dependencies between subsystems possible). Historically a subsystem has following structure (simplified) subsystem-root | -src | - bno (contains client sources of this subsystems guis etc.) | - cl (contains client sources from other subsystems) | - co (client/server-shared sources, transfer objects, session facade interfaces etc.) | - gl (contains serverside sources of this subsystem) | - srv (contains serverside sources from other subsystems) For each of my own source parts (bno, co, gl) a eclipse project is created (located in this folders). For the cl/srv part no projects are created, because "normally" I don't mess with sources from other subsystems, so the sources in this folders are not compiled (the sources are already compiled and installed by our make environment, so they contain all class files). Ok, now i try to explain the dependencies between the created projects. The co-project is the first project created, it needs the sources from the cl-part (because therein also lie the client/server-shared sources from the other subsystems) so the cl-Folder is linked into the co-project. The cl-Folder becomes part of co's buildpath but should not get compiled. The bno-project is created second and references the co-project AND also links the cl-part. The cl-folder is also part of bno's buildpath and should not get compiled (therefor its excluded). The gl-project is created last and referenced the co-project too AND links the srv-part. The srv-folder is part of gl's buildpath and should not get compiled. As last point is to say that the bno-project is not allowed to have gl/srv-parts on its classpath (because serverside sources are not allowed on the client), so its a strong separation between client and server code. Thats why our eclipse project structure is a bit twisted, but works well (except the reported shortcoming). The subsystem-structure cannot be changed, because the project runs quite a time (several years), so we have to live with this structure. I hope that explains the problem a bit to you. Over the weekend i try to make a simple test project, that shows the problem. Thank you Lars Hapke
I checked the problem another time. The problem does not occur within the Navigator perspective, but only in the java perspectives (Java Browsing, Package Explorer).
Ok, fine. I need some time to try to understand the layout you described and your .classpath. One question though. Why is your project a source folder? Why don't you use a separate source folder inside your project and then you can define a different output folder.
Created attachment 4563 [details] A simple test project to show the behaviour Hi, I made a simple project to show the behaviour. I said before the problem only occurs in the java-views, which was not quite true. It occurs in the navigator too when the .class file is opened instead of the .java file (I usually filter *.class files from the navigator). If I open a resource from the linked classfolder in the java-views, the .class file is always opened. I think this is a general problem with linked classfolders, not a specific problem with my project layout. As I understand it, these linked folders are the only way of adding a source folder that lies outside the project to the projects class(build)path. Before 2.1 it was not possible to add such folders to the classpath of a project, it was only possible to do that with libraries (zip, jar...). To your question: Each of the 3 project (bno,co,gl) is a sourcefolder or has all of its contents as sources. A strong seperation between client and server sources is needed. It is not allowed for client code to reference classes that are only on the server. I could have made a single project with three different sourcefolders (bno,co,gl) and give a specific output folder to each of this parts. But in this case, all three sourcefolders are on the class(build)path and there is no way to prevent that a programmer uses serverside classes, because a single project has a single classpath. I don't know if this explains something to you, I admit that it is complicated and twisted. I propose we start over with a simplier approach: New Problem Description: ;-) I have a eclipse project that needs a classfolder that lies outside the projects location on its classpath. I used the new posibillity of 2.1 to link this folder into my project and added this linked folder to my projects classpath. If a class-file from this linked folder is opened (navigator or java-views), the outline and the editor do not synchonize. The problem can be reconstructed with the zip file I appended. Thank you very much, you have been very patient with me Regards, Lars Hapke
I reproduced your problem. Your problem is that there is no source attached to your class folder. If you select your class folder in the java build path properties page, expand it and select the source attachement property. Attach it to the same folder (C:/36337_test/linkedSources). You will end up with a .classpath looking like this: <?xml version="1.0" encoding="UTF-8"?> <classpath> <classpathentry kind="src" path="src"/> <classpathentry kind="con" path="org.eclipse.jdt.launching.JRE_CONTAINER"/> <classpathentry kind="lib" path="linked" sourcepath="C:/36337_test/linkedSources"/> <classpathentry kind="output" path="bin"/> </classpath> And then you will have the synchronization you are looking for. Hope this help. However I would say you should not get any source, if there is no source attachment. I will investigate why you get a source. Does it work for you?
To be more specific, in your test case: <?xml version="1.0" encoding="UTF-8"?> <classpath> <classpathentry excluding="linkedSources/" kind="src" path=""/> <classpathentry kind="con" path="org.eclipse.jdt.launching.JRE_CONTAINER"/> <classpathentry kind="lib" path="linkedSources" sourcepath="C:/36337_test/linkedSources"/> <classpathentry kind="output" path=""/> </classpath> I had slightly changed the layout of your project. Please confirm me that it works if you attach the source.
Hi, yes, it works perfectly. Thank you very much. I always thought he would get the source automatically if it lies in the same location. Maybe because he actually did find "some" source but not quite right.. Thank you again Lars Hapke
In fact we could keep this "feature". What it means is that if the source is in the same location, then JDT/Core would automatically attach the source. In order to have the outliner to be synchronized, the source attachement needs to be there. In fact the right behavior should have been no source returned, because the compilation unit located in a class folder is not supposed to exist in the Java model context. I entered a feature request to keep this behavior when bug 36499 is fixed. See bug 36510. Ok to close?
Yes, very well, you can close this one. At least my report was not fully useless ;-) Thanks for your help, Lars Hapke
Closed. This is exposing a bug (see bug 36499), but it actually works as expected if the source is properly attached.
A PR is never useless. In this case, because of a bug, you could not guess that you had to attach the source. So this bug will be fixed and we will try to keep the "feature" of automatic source attachment when a source is available when the .class file is.
