Community
Participate
Working Groups
Fup of bug 336632, the API Tools builder doesn't force a full build when org.apache.ant is replaced with a newer version. apt.core project has this project on its classpath and should therefore be rebuilt if org.apache.ant is replaced with a newer version. This happens in AUTO_BUILD mode where the Java builder detects the classpath change and does a full build of apt.core. The API Tools builder doesn't see the classpath change and as there is no other changes, it doesn't rebuild the apt.core project. This is causing some problems not to be removed. See bug 336632 comment 7.
I wonder if we could not use the org.eclipse.pde.api.tools.internal.WorkspaceDeltaProcessor class to flush the build state for a project for which we get a delta that has the flags IJavaElementDelta.F_RESOLVED_CLASSPATH_CHANGED or IJavaElementDelta.F_CLASSPATH_CHANGED) set.
(In reply to comment #1) > I wonder if we could not use the > org.eclipse.pde.api.tools.internal.WorkspaceDeltaProcessor class to flush the > build state for a project for which we get a delta that has the flags > IJavaElementDelta.F_RESOLVED_CLASSPATH_CHANGED or > IJavaElementDelta.F_CLASSPATH_CHANGED) set. That makes sense to me, although we already tag the API description for the project as having a classpath change, perhaps instead of toasting the build state we could just add a check to see if the backing project's API description is in sync? I was thinking of this in terms of the fix for bug 290324, where we now save the last built state of the manifest and build.properties for a given project in the build state. So if we just toast the build state, a no-op change - or one for a header we don't care about - will cause a full build when it should not.
(In reply to comment #2) > That makes sense to me, although we already tag the API description for the > project as having a classpath change, perhaps instead of toasting the build > state we could just add a check to see if the backing project's API description > is in sync? Sure. I'll let you do it then since you changed it recently.
Created attachment 192877 [details] fix I tried implementing the fix both ways: 1) toasting the build state and 2) checking for the API description sync state. Both worked pretty much the same, and proved my concern about the manifest state being unfounded. The patch implements Olivier's original idea of just removing the last saved build state for any project whose classpath changes - the fix is smaller than asking for API components / descriptions.
applied patch to HEAD please verify Olivier.
Looks good.
