Community
Participate
Working Groups
Auto-build is on. I select a bunch of Java projects and load them from the repository but they are built in the wrong order, thus producing lots of errors. If I rebuild the workspace it works OK. NOTES: PM (6/11/2001 5:44:38 PM) JavaCore is no longer responsible for setting the build order. Moving to ITPJUI. DJH (6/11/01 1:22:30 PM) This may be Core. Moving to CORE for investigation. DJH (6/11/01 3:01:05 PM) Note that the "red X's" don't appear on the Java projects in the packages view. But they do appear on the packages/classes icons. DJH (6/11/01 4:07:40 PM) Got a simple reproduceable test case. Ensure auto-build is on. The end result is that there are problems in tests.harness saying that it can't find references to junit classes. Rebuilding the project fixes these problems. From cvslnx.ott.oti.com load (by selecting all at once and "Add to Workspace"): org.apache.xerces org.eclipse.core.boot org.eclipse.core.runtime org.eclipse.core.resources org.eclipse.core.tests.harness org.junit I checked the BuildManager (via breakpoints) and since this the first time building, the build order is being calculated. The result of the calculation is the correct order. (junit is before tests.harness - tests.harness is actually last in the list) Note that the build order shouldn't matter since tests.harness references a JAR in the junit project and not junit source which has to be compiled. Not sure why this is happening. Moving to JCORE for comment. PM (6/12/01 12:16:17 AM) The Java builder does not do anything with respect to build order. If it is invoked in the right order, then it will perform correctly. Either the JUI does not set the build order correctly, or the platform does not honour the order. If manually building each project individually in the proper order makes thing work fine, then this is definitely not a JCORE problem. DJH (6/12/01 10:36:25 AM) Steps to reproduce. Works every time. To get correct behaviour: - install and startup fresh 0.122 build - close Welcome window - close Resource perspective - Window -> Preferences - Workbench -> New Project Options -> Do Not Switch - Java -> Classpath Variable -> Add - TARGET = folder "c:/eclipse/plugins" (or wherever you have another install (used to get xerces.jar)) - OK - Open Perspective -> Team - switch to Repositories view - right click and select New -> CVS Repository Location - fill in the information for the core repository - use the Navigator to expand HEAD team stream - select projects: org.apache.xerces org.eclipse.core.boot org.eclipse.core.runtime org.eclipse.core.resources org.eclipse.core.tests.harness org.junit - right click and Add to Workspace Note that workspace is built correctly and there are no problems. To get incorrect behaviour: - perform the above steps exactly except before you open the Team perspective, open a Java perspective as well. - ensure that you are doing this from a fresh install - after you Add to Workspace you will get problems because classes in tests.harness cannot see the classes in junit Note that the build order is the same (and correct) every time. Note that the only difference is that the Java perspective is visible. Weird.... DJH (6/12/01 1:18:28 PM) Moving to JUI for comment since the Java perspective may have something to do with the problem. EG (6/12/2001 8:59:08 AM) The only class path related operation happens during plugin activation from the steps above it looks like the JUI plugin is already activated. Need to reproduce. Should investigate. TM (6/13/2001 11:20:54) Findings: 1) there are errors on the source folders in org.eclipse.core.runtime, but not on the project. This should never happen. Note that if you don't open the java perspective first, the errors do appear on the projects. Seems to be an update problem. 2) The activation of the java plugin cannot be the problem here. If you set a variable, you have passed through the java UI plugin activation code. 3) Note that the variable TARGET is shown as non-resolvable (a white dot). 4) rebuilding org.eclipse.core.resources doesn't fix the errors in that project. If I reset the variable TARGET (not change it, just remove and readd it to the project build path), the errors go away. 5) rebuilding the test harness project makes the errors go away in there. 6) this can't be a build order problem: junit.jar doesn't have to be compiled. I figure it's the same problem that prevents the variable from being accessible in org.eclipse.core resources. Conclusions: 1) It's not a build order problem. JUnit.jar doesn't have to be compiled, so the problem can't be that it's not compiled. 2) It's not a problem of Java UI plugin activation. The plugin is activated both times when setting the TARGET variable. 3) We don't manipulate the classpath when opening the java perspective. 4) We don't manipulate the classpath when loading projects from the repository. The only difference I can imagine with the Java perspective loaded is that we access the java elements, which doesn't happen with only the team perspective open. Also, the appearently unresolvable TARGET variable (although the file is there, I checked) seems fishy. This leads me to believe that the problem lies with the initialization of the classpath and variables in the java model. EG (23.07.2001 11:18:07) moving to JCORE for comment
This is a direct consequence from the fact that a VCM load is only perceived as a resource change, and the JavaModel cannot change project references when reconciling with the new .classpath file. Project references cannot be updated: * when noticing the .classpath change because it is too soon (still inside change notification) * when building, because it is too late So we leave them as is. Only the JavaUI updates them when doing the classpath change in the UI. This is not acceptable, but given the current design of the platform, I do not see how we could solve this one.
PRODUCT VERSION: 0.122 JRE on Win98
*** This bug has been marked as a duplicate of 3435 ***
