Community
Participate
Working Groups
Version: 3.1.0 Build id: 200409011200 Workspace Setup: - have many plug-ins (source and imported binary projects) - enable Build automatically - enable Always run in background - only Java Browsing perspective - a source project selected (so that packages view is filled) Test Scenario: 1. start above workspace 2. observe: many blocking dialogs appear: build kicks in several times if you don't see this: exit and go to 1. I created VM dumps and found out that while the Packages view is fetching the elements PDE calls setClassPathContainer which seems to trigger a build: org.eclipse.jdt.core.JavaCore.setClasspathContainer(JavaCore.java:3509) org.eclipse.pde.internal.core.ModelEntry.updateClasspathContainer(ModelEntry.java:109) org.eclipse.pde.internal.core.RequiredPluginsInitializer.initialize(RequiredPluginsInitializer.java:40) org.eclipse.jdt.internal.core.JavaModelManager.initializeContainer(JavaModelManager.java:1262) This seems to happen several times and hence auto-build kicks in several times. Sometimes it even looks like a full build is done. Note: it does not happen when using the Java perspective. I guess this is because all projects are collapsed and it does not restore the selection. Why needs the classpath to be set if I exited my workspace in a completely OK state?
Created attachment 14423 [details] VM dump 1
Created attachment 14424 [details] VM dump 2
I enabled JDT Core tracing. Unfortunately I couldn't grab the whole console (need to redirect console to a log file). Attached are two different snapshots of the console log. Does "FULL BUILD" in the log mean full workspace build (at least it looked so to me) or project rebuild?
Created attachment 14482 [details] Console snapshot t1
Created attachment 14483 [details] console snapshot t2
FULL_BUILD means: project rebuild.
This happens to me too. I'm usually either in the regular Java Perspective or Debug Perspective. I couldn't think of a reason for the rebuilds but didn't realize it was unintentional.
>Why needs the classpath to be set if I exited my workspace in a completely OK >state? The classpath container of a plugin is dynamically computed at every startup. This does not usually result in a rebuild (neither partial nor full) if your external plugins(i.e. target platform) have not changed from one invocation of the workbench to the next. However, if your target platform did change, then a rebuild (partial or full, as per JDT/Core's discretion) is expected because your workspace plugins are now compiling against new JARs. I profess that I have limited understanding of the JDT/Core tracing stacks, but in this case, it appears to me that JDT determined that your external JARs have certainly changed since the last startup and that is why a build was invoked. Philippe, is this what is happening here? If so, then it's expected behavior.
The runtime with which I started Eclipse might have changed (I'm pretty sure it also happened when I did not change it) but that must not trigger any kind of build since all my external plug-ins are fully imported and not linked - just verified again to be sure. I have also unchecked all plug-ins on the PDE target platform preference page.
Moving to JDT/Core since they are the ones who determine if/when a build is needed. Personally, I have not encountered a false build since the resolution of bug 63756
If PDE container did not resolve to anything outside the workspace (as per Dani's comment), then there is no reason for a rebuild to occur. We need a trace in order to figure what's going on. Please enable following traces in .options file: # Turn on debug tracing for org.eclipse.jdt.core plugin org.eclipse.jdt.core/debug=true # Reports classpath variable initialization, and classpath container resolution org.eclipse.jdt.core/debug/cpresolution=true # Reports incremental builder activity : nature of build, built state reading, indictment process org.eclipse.jdt.core/debug/builder=true
Jerome - pls try to reproduce in latest
Between 2 sessions, if I neither change the Eclipse build nor the VM, I'm not seeing this problem with I20040928. Does anyone CC'ed on this bug report see a full build under those conditions ? If you do, can you please turn on the debug traces as indicated in comment #11. Don't forget to increase the buffer size of your DOS console (if you're working on Windows). Then please copy/paste the entire output in a file that you attach to this bug report. Thanks.
Sorry Jerome. I, for one, don't see it and haven't seen it in months.
I didn't see it in latest builds. Don't the console snapshots help? Jerome: could I be caught be the too small cache problem? I have many projects in my workspace (118, 45 Java source projects).
Unfortunately the console snapshots are incomplete, and they don't include the classpath resolution trace. I doubt the size of the Java Model cache would have any effect on this problem (and there is no longer a limit for projects anyway)
I haven't noticed it in recent builds like 3.1M2.
Please reopen if you see it again and have debug traces as indicated in comment #11.
