Community
Participate
Working Groups
Build 20020521 If you load projects into the workbench more than one at a time if there is already a version of the project in the workbench with the same java build path it wil not get updated properly. STEPS 1) Import all of Eclipse are binary projects using the PDE import 2) Open a CVS repository connection to dev.eclipse.org 3) Select org.eclipse.core.resources, org.eclipse.core.resources.linux, and org.eclipse.core.runtime 4) select Check out a project. You will have errors because org.eclipse.core.resources will still have a reference to its (now deleted) jar file. 5) load org.eclipse.core.resources by itself. The problem will go away
Mike, please investigate.
Tod, does step (5) follow immediately after the other steps, or did you reimport everything and try just importing the one? I am trying to understand if it works differently if you do just one, or do many. PDE now un-PDE's a project when its loaded from source. So I think this bug may have gone away. If I do step (5) on its own in today's build it works ok.
Step 5 is just a step to verify that loading one of them by itself works. It is discrete from the others and should work if you do it by itself.
This still occurs in F2 when you check out multiple projects. It appears that the .classpath file of the first loaded project does not get overridden but the others do. That is why loading one project does not have this problem. Someone is overwriting the .classpath that is loaded from the repository with what they have in memory. Perhaps the scenario is something like "get the delta for the first .classpath and the write out all .classpaths before the delta for the others are processed". I'm not sure if it's a PDE problem or a JDT problem so I'm forwarding it to PDE.
Actually, I think JDT is a better palce for this.
*** Bug 17485 has been marked as a duplicate of this bug. ***
The .classpath file can only be overriden if: 1. discarded by mistake (marker is now being added if this scenario occurs) 2. someone changed the classpath using IJavaProject#setRawClasspath Moving to PDE for investigation
It is definitely a JDT issue, not a PDE issue. PDE overwrites the classpath only when the user explicitly runs the 'Update Classpath' action. Another place when PDE sets the classpath is during the 'import external plugins and fragments' operation. In both instances where PDE acts on the classpath, the classpath is updated correctly. The whole check-out procedure and subsequent problems described above have nothing to do with PDE. Moving to JDT... cc: Andrew because he opened a related defect - bug 24450
*** Bug 24450 has been marked as a duplicate of this bug. ***
Is it still an issue ?
Just verified with M2 that this is still an issue.
I cannot reproduce with build 20021018 (M2) following Tod's steps or Debbie's steps. In both cases, the .classpath files are in sync with the repository, and everything builds fine. Do either of you have more info?
I got the problem with M20021018 but not with I20021018. Debbie, by any chance did you use M20021018 to test it?
I got this with the build currently labelled as M2 on the eclipse.org downloads page. The label for the zip file is eclipse-SDK-I20021018-win32.zip which I believe is the 2.1 stream and not the 2.0.2 stream which is where you are seeing the problem.
I tried again with build M2, and could not reproduce. Something must be missing from the steps...
I cannot replicate in 20021023 either.
Unable to reproduce with M2 today - gotta stay away from that cough syrup. Sorry for making you try it again.
So is it ok to close?
OK by me. BTW I think the problem Deb was seeing was the PDE bug that wipes out your ECLIPSE_HOME.
OK by me too
Closing
