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

Bug 114857

Summary:	classpath variable change listener
Product:	[Eclipse Project] JDT	Reporter:	Walter Harley <eclipse>
Component:	APT	Assignee:	Generic inbox for the JDT-APT component <jdt-apt-inbox>
Status:	CLOSED WONTFIX	QA Contact:
Severity:	normal
Priority:	P3	CC:	konstantin
Version:	3.1
Target Milestone:	---
Hardware:	PC
OS:	Windows XP
Whiteboard:	stalebug

Description Walter Harley

2005-11-02 18:23:48 EST

Processor jar files can be specified relative to a classpath variable.  
Therefore, when the user redefines a classpath variable, we should dump the 
processor cache for any projects whose factorypath has var-relative jars, clear 
problem markers, revalidate the factorypath, etc.

Similarly, we should be watching for deletion and possibly creation of 
classpath variables.

We already perform these actions (or are about to, anyway) when the jar files 
themselves, or the factorypaths, change; the relevant code is in 
AnnotationProcessorFactoryLoader.

Comment 1 Walter Harley

2005-12-09 20:51:39 EST

There does not appear to be any way to listen for changes to classpath variables.  However, the classpath variable preference UI already offers to rebuild if variables are changed; and there is no other way for them to change, because classpath variables are not version-controllable (since they're at the workspace level rather than per project).

So, resolving this as "won't fix".

Comment 2 Walter Harley

2005-12-09 20:54:45 EST

Although, rebuilding doesn't help here because it won't flush the processor cache.  But the bottom line is there doesn't appear to be any reasonable way with existing APIs to catch this event.  The two options would seem to be:
1) Add an API to JDT to let plugins register to listen to classpath variable changes.
2) Dump the processor cache on every build, or at least on a clean.

I'm not sure this problem is important enough to bother with either one.  Leaving it to see if anyone in the real world complains.

Comment 3 Walter Harley

2006-11-16 16:56:51 EST

Reopening per bug 159535.

Comment 4 Walter Harley

2006-11-16 17:31:47 EST

*** Bug 159535 has been marked as a duplicate of this bug. ***

Comment 5 Konstantin Komissarchik

2006-11-16 18:12:20 EST

Couldn't you keep the list of vars and their values that you used to initialize the processor cache with (along with any vars that you couldn't resolve)? You could then compare that agains the current state on every build and know whether you need to dump the processor cache. This way a rebuild takes care of the problem, which is what users would expect.

Comment 6 Walter Harley

2009-08-03 17:01:45 EDT

Reassigning to jdt-apt-inbox, per http://wiki.eclipse.org/Platform_UI/Bug_Triage_Change_2009.

Comment 7 Eclipse Genie

2020-02-06 15:09:37 EST

This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. As such, we're closing this bug.

If you have further information on the current state of the bug, please add it and reopen this bug. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.

--
The automated Eclipse Genie.