Bug 45707 - Autobuild does not kick in when using classpath containers
Summary: Autobuild does not kick in when using classpath containers
Status: VERIFIED FIXED
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 3.0   Edit
Hardware: PC Windows XP
: P3 normal (vote)
Target Milestone: 3.0 M5   Edit
Assignee: Philipe Mulet CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2003-10-28 23:08 EST by Wassim Melhem CLA
Modified: 2003-11-24 12:39 EST (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Wassim Melhem CLA 2003-10-28 23:08:57 EST
One way PDE provides a sharable, dynamically adaptive classpath for plug-in 
projects is through the use of classpath containers.  As people check out 
projects from CVS, import external plug-ins, delete projects, etc., the 
classpath of a workspace project is dynamically computed and hence always up-
to-date.

However, after the introduction of background autobuilding, even though the 
classpath does dynamically change, autobuild does not kick in.
My conjecture (I love this word :-) is that autobuild does not kick in because 
the .classpath file does not change.  Ironically, the fact that the .classpath 
file does not change is one of the attractive aspects of classpath containers.

Doing the dynamic update in an IWorkspaceRunnable() does not help invoke 
autobuild in this scenario.

A hack (which will be in Wednesday's I-build), as suggested by one John 
Arthorne, is to do a project.touch(monitor) on the projects for which we are 
updating the classpath, fooling autobuild into thinking that resources have 
changed.  This certainly seems to work.
Comment 1 Philipe Mulet CLA 2003-10-29 04:52:59 EST
I will adopt this defect since it is rather an issue in JDT Core. The container 
support should trigger the touch in situations where a rebuild is necessary but 
no resource is touched.

Similar issue with classpath variables.
Comment 2 Philipe Mulet CLA 2003-10-29 11:05:50 EST
Added project.touch(...) invocation inside the APIs for setting cp containers 
and variables (only on affected projects in case the new value is different 
from old one).
Comment 3 Philipe Mulet CLA 2003-10-29 11:06:11 EST
Fixed
Comment 4 David Audel CLA 2003-11-24 12:39:50 EST
Verified.