Community
Participate
Working Groups
Build Identifier: M20110909-1335 Hi, here's my setup: Project P1: src (source folder) src_shared (src_shared) Project P2: src (source folder) src_shared (linked resource pointing at WORKSPACE_LOC/P1/src_shared, source folder) Now src_shared contains a file called Foo.java. Sidenote: Double clicking P1/src_shared/Foo.java opens one editor and double clicking P2/src_shared/Foo.java opens another editor, which do not share contents. One editor reloads the file when the file has been saved in the other, etc. Now about JDT: When applying refactoring in the editor of P1/src_shared/Foo.java, the classes in P2/src are not affected by the refactorings. Also, the refactoring of P1/src_shared/Foo might result in errors in P2 which the refactoring dialog doesn't warn about. The same applies to P1 if you refactor P2/src_shared/Foo.java. Background: Imagine that the src_shared folder contains interfaces and classes that are shared between P1 and P2 and implemented/used by the classes in P1/src and P2/src. Unfortunately, I can't create an seperate project for the interfaces/classes in src_shared, so that P1 and P2 can depend on it. The thing is, that P1 contains a reimplementation of a subset of the JDK runtime (packages java, javax, etc.) while P2 is a project with a normal Oracle eJDK runtime in the classpath. The interfaces must be compiled for both runtimes. P1 is the java runtime that runs on the Lego NXT brick (see http://www.lejos.org for details. Currenly we copy the sources from P1/src_shared to P2/src_shared using ant. As you can imagine, using linked resources is much more convenient. But you could also imagine P1 to be an android project, in which case the interfaces/classes in src_shared would have to compiled for both a normal Oracle JDK or the android runtime. Reproducible: Always Steps to Reproduce: create a setup like described above and refactor src_shared/Foo
Search on the workspace scope was trying to optimize the searches by looking at only the dependencies and as there is no direct dependency, this is not being searched. I will try to get some way without impacting the performance.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
