Community
Participate
Working Groups
(patched) M5 Not reproducable: I added several projects and ended up with a cycle that was not reported. Guess: A second error caused us not to update markers. (working on a test case) Simple test case that causes the opposite problem (left over cycle markers when there is no cycle) 1. Create a project A. 2. Create a project B with A on its classpath. 3. Add B to A's classpath. now you have a cycle. 4. Delete A. now the cycle is gone, but the cycle marker is still on project B
We have noticed defficiencies in cycle detection around M5 due to some optimizations which didn't work. Should be fixed in 20020501.
In 20020501 (and 0502), we issue too many cycle markers (see bug 15091). This is been resolved in latest.
Fixed
I can still reproduce both my problem (and the simple test case below). I will try to provide a reasonably sized test case by Monday.
I was able to reproduce the simple test case. This is due to the fact that JavaProject.updateAllCycleMerkers() doesn't check if the project is being deleted. Another test case that causes cycle markers not to be reported is: 1. Create project B with A on its classpath (but A does not exist yet) 2. Create project A with B on its classpath (it has to be done in one operation) The cycle on B is reported, but it is not reported on A. This is because JavaProject.updateAllCycleMarkers() doesn't consider A since it is not in the Java model yet.
I believe I have discovered a more serious limitation. If the java core plugin is not loaded in advance of the project changes, circularities will not be detected. Test case: 1. create a java project A that has B on its classpath and B that has A on its classpath. Create these projects in a directory c:\test (outside the workspace). 2, start a new workspace. TURN AUTOBUILD OFF. Do not go to the java perspective - do nothing except the steps mentioned below. Stay in the resource perspective. 3. Import external project A. 4. Import external project B 5. Press build. No circularities are detected. If you now alter the preoject dependency graph further, problems will be discovered.
I just reproduced this will autobuild on. I am still missing something.
I cannot reproduce the last test case with autobuild off: before I press build, no cycles are reported (expected since jdt core is not loaded), and after I press build the cycle is reported on both projects A and B. With autobuild on, I can reproduce. Here is what I see: - when importing A: the same 2 markers are created. They both indicate that B is missing. - when importing B: the 2 above markers are removed, but no cycle markers are created.
I missed one key point (entirely unintentionally). Almost the same test case - 1. create a java project A that has B on its classpath and B that has A on its classpath. Create these projects in a directory c:\test (outside the workspace). 2, start a new workspace. Do not go to the java perspective - do nothing except the steps mentioned below. Stay in the resource perspective. 3. (MISSING STEP) Define a classpath variable JUNK (value = c:\temp). 4. Import external project A. 5. Import external project B Step 3 shouldn't make a difference - it isn't used, but it does. My earlier test used an empty workspace with classpath variables defined - that is why it allowed me to reproduce the steps.
Problem is that when jdt/core is started, we no longer have a delta indicating a project was added. Thus we will not trigger a cycle marker check. We could defensively force a cycle marker update on plugin startup, but this would still not be optimal in so far as markers would not appear until you create the variable. Where they should show up at the moment the projects are brought in (problem similar to inconsistent initialization of JRE_LIB var when activating the Jdt/UI - we did introduce a mechanism for allowing early activation of classpath variable initializer). I am not getting why the import of Java projects did not trigger the activation of the Jdt/core plugin. If I am building, then yes it will be loaded due to the Java builder activation, so why not loading Jdt/Core initially ?
I assume John's steps are still with autobuild off. In this case, I see only one project with a cycle marker, the other one is missing a cycle marker.
Note that when the JUNK variable is created, jdtcore is started and we listen for changes thereafter.
Fixed the first test cases by updating the java model (i.e. by adding/removing projects to/from their parent) before the updateCycleMarkers is called. Also keep the list of projects before processing the delta. This list is used by the delta processor to find out if a project was a java project before.
Updating cycle markers on plugin startup will be reviewed post 2.0, unless this become critical.
