Community
Participate
Working Groups
build from i0323/i0324/i0325 I noticed this lately because I am upgrading my dev drops a lot. Everytime I upgrade to a new drop, a full build happens when I first start up the workspace. Subsequent sessions are ok (no full build) until I upgrade the dev. I am using PDE classpath containers but everything in my workspace is being recompiled, including runtime and osgi which have no external plug-in dependancies. I'm putting the bug in PDE/UI since I'm guessing that it relates to the changing locations of external plug-ins. The contents of my workspace include all the following projects from HEAD from dev.eclipse.org: org.eclipse.core.resources.hpux org.eclipse.core.resources.macosx org.eclipse.core.resources.qnx org.eclipse.releng platform-core-home org.apache.xerces org.eclipse.core.boot org.eclipse.core.resources org.eclipse.core.resources.linux org.eclipse.core.resources.win32 org.eclipse.core.runtime org.eclipse.core.runtime.compatibility org.eclipse.core.tests.harness org.eclipse.core.tests.resources org.eclipse.core.tests.runtime org.eclipse.osgi org.eclipse.osgi.services org.eclipse.osgi.util org.eclipse.pde.build org.eclipse.platform org.eclipse.webdav
PDE does not directly invoke builds. I'm not sure who is doing it and when they do it. Is it JDT/Core? cc JohnA and Philippe for comment.
JDT core will cause a full build when the classpath changes. Since the classpath resolution is delegated to PDE, I don't know who is to blame here.
The real question is though: Is anyone to blame? or is this a fact of life?
A valid question, but I think this was only introduced recently so it might be a regression (maybe due to changes for dynamic project references).
"You take the good, you take the bad, you take them both and then you have...the facts of life, the facts of life." Sorry, reference to 80's show there. I can't think of a good reason for re-compiling runtime and osgi when they have no external dependancies. Nothing in their classpaths would have changed.
DJ, I don't experience the full build experience that you do upon startup. However, the long running background op that I do experience on startup, is some Team synchronize operation. Are you sure it's a full build?
Pretty sure its a full build. - "cleaning output folder" - "compiling org.eclipse.core.runtime" - etc. (you should get a full team synchronize the first time you switch to the Team perspective if you have auto-scheduled syncs turned on)
DJ, do you still see the problem on RC1 and later? This looks like it might be a dup of bug 63756, entitled "Multiple Builds Early".
It definitely looks like a dup of bug 63756. Problem was if multiple threads were initializing classpath in parallel, there was a window for one to persist an intermediate partially resolved classpath (while other thread was in middle of container initialization); and then autobuild could kick in, and decide that the partial classpath was too different from the one recorded in previous build state, thus Java builder decided it was a good time to rebuild entirely. Should not happen with RC1 build any longer. *** This bug has been marked as a duplicate of 63756 ***
