Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 341524

Summary:

API Tools builder doesn't detect classpath changes

Product:

[Eclipse Project] PDE

Reporter:

Olivier Thomann <Olivier_Thomann>

Component:

API Tools

Assignee:

Michael Rennie <Michael_Rennie>

Status:

VERIFIED FIXED

QA Contact:

Severity:

normal

Priority:

CC:

Michael_Rennie

Version:

3.7

Flags:

Olivier_Thomann: review+

Target Milestone:

3.7 M7

Hardware:

OS:

Windows 7

Whiteboard:

Attachments:

Description	Flags
fix	none

Description Olivier Thomann

2011-03-31 13:02:50 EDT

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.

Comment 1 Olivier Thomann

2011-03-31 13:20:03 EDT

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.

Comment 2 Michael Rennie

2011-03-31 13:41:50 EDT

(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.

Comment 3 Olivier Thomann

2011-03-31 13:45:04 EDT

(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.

Comment 4 Michael Rennie

2011-04-08 15:36:20 EDT

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.

Comment 5 Michael Rennie

2011-04-08 15:37:17 EDT

applied patch to HEAD

please verify Olivier.

Comment 6 Olivier Thomann

2011-04-19 15:04:03 EDT

Looks good.