Community
Participate
Working Groups
Hi there, I have a project A and another project B that uses the first one as required project (project - properties> Java Build Path > Projects). Now I get compilation errors in project B: The import ... can not be resolved, but the imported class is in project A. The funny thing is, when I go to that import statement and hit [Ctrl.][Space] the problem dissapears. But whenever I rebuild the project, it comes up again. I tried to refresh and rebuild all projects, restart eclipse, etc. but without effect. Since that abstract Class in A is used a lot in B there is not much fun in fixing this problem by hand every time the project is rebuild. Version 2.1.0., BuildId is 200303192032. Regards Jörg
Weird. We use project references in our every day life and haven't since this issue. Your setup must have something unique which makes this situation arise. Could you provide a test case which would reproduce this ? The simplest would be to create a small workspace reproducing this issue, and attach it to this bug report.
It seems you are right with "something unique which makes this situation arise". Unfortunately this occured in a business project and I can not just send the project to you. I am trying to reduce the situation to something small enought to be able to publish it here. But I have to do this in my spare time (I am not payed for bug-reports)... What I found out is: -I moved my eclipse workspace dir to a backup folder and imported the projects A and B as existing projects. The problem is still there! This does not seem to be a problem in the .metadata -when I create a new class in the project B, that extends the "unresolved" abstract class from the dependend project A, everything seems fine, while in the same package there is an existing class that has the reported bug. -When I leave the mouse cursor above the class-path of the "incorrect" import statement, I get a tooltip "The import ... can not be resolved", while when I place the cursor somewhat to the end of it, I get the correct documentation statement of that class. Thats it so far...
Hi again, that was a quick one: If found the problem... In the project B there was a package named exacly like the package in A where that abstract class is loacted that caused the trouble. Everyting occured because I use CVS and that package was moved from B to A and I did not select "prune empty directories" for my CVS client. Now you have to decide if this is still a bug. At least some handling could be added for such situation (warning or so). Regards Jörg
*** Bug 36440 has been marked as a duplicate of this bug. ***
There isn't anything wrong with having 2 projects define the same package, even if one depends on the other... The only problem I can duplicate is this one: Project A defines a public type p1.X in p1/X.java Project B has a leftover non-public type p1.Deleted in p1/X.java, and another type p2.y in p2/Y.java that extends X. A build of the Project B causes both p2/Y.java & p1/X.java to be compiled together (resulting in compile errors because X.java does NOT contain the type X). Incremental builds find the type X in the project p1 so the compile errors go away. Any chance that this is what happened?
Do you remember all the compile errors you were getting? Did you get some like: 'The import p1.X cannot be resolved' and 'X cannot be resolved or is not a valid superclass'
Too bad that I did not make a full backup before I tried to fix the problem. Currently I can not find a way to reproduce the situation. What I remember is: -the duplicate package (as you call it p1) in B was viewed as non empty in the packages view (organge package symbol) but when I clicked on it, no type was listed. -as I selected that package and did a delete, the project was viewed as empty (white package symbol) and the problem was gone. -the package contained and still contains a CVS dir from an external CVS client, while the projects A and B are not team projects. The compile errors were exactly the same as when I now delete the type (X) from p1 in the project A (but more than the two you mentioned, because the subclasses of X in project B did use methods defined in X). The situation was not exactly as you described: > Project B has a leftover non-public type p1.Deleted in p1/X.java p1 was originally in B and was completely copied to A in the filesystem. Using an external CVS client, p1 then was deleted in the location of B (in CVS and filesystem). So A/p1/X and B/p1/X were exactly the same, (and X is public and abstract). If I would have a backup I could have a look at B/p1 what was left in there to cause the problem. Maybe a readonly class file or something strange. I think what we can say is that the bug I found only occures in a very special situation and is not too bad. Whenever I will be able to reproduce the sitation, I think I will be able to tell you how to reproduce the behaviour in general.
Reopen this PR if you can reproduce the problem you had.
