Bug 9190 - Removing a library from classpath gives not a remove delta
Summary: Removing a library from classpath gives not a remove delta
Status: RESOLVED WONTFIX
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 2.0   Edit
Hardware: PC Windows 2000
: P1 normal (vote)
Target Milestone: 2.0 M3   Edit
Assignee: Jerome Lanneluc CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2002-02-06 13:33 EST by Martin Aeschlimann CLA
Modified: 2002-02-07 13:24 EST (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Martin Aeschlimann CLA 2002-02-06 13:33:27 EST
When deleting a library classpath entry from the classpath, the element delta 
resulted from this change is
  PackageFragmentRoot kind: changed, flags: removed from classpath

The root has no affected childeren.

I would have thought that kind is 'removed', or that all types in the JAR will 
be reproted as removed.

Is there a document that defines how deltas look like?
Comment 1 Philipe Mulet CLA 2002-02-06 17:49:04 EST
I believe we are consistent with the platform, when adding or removing a parent 
element, its children are not reported (there are all implicitly added/removed 
as well). Only when it is changed, will you get finer grain information with 
children deltas.

I guess this was changed in build 20011204.

Jerome, do we have a spec for expected deltas ? Couldn't find any handy.
Comment 2 Martin Aeschlimann CLA 2002-02-07 04:12:40 EST
ok, then PackageFragmentRoot should be kind: removed
Comment 3 Jerome Lanneluc CLA 2002-02-07 12:59:16 EST
Unfortunately, there is no spec yet. Bug 3329 captures the need for a java 
delta spec.
Comment 4 Jerome Lanneluc CLA 2002-02-07 13:24:08 EST
We could say that 'removed' would indicate that the resource has been removed. 
In this case, it still exists. So it is just 'removed from classpath'.

I agree that this explanation is not great (i.e. it is not true for sub-cu java 
elements as they may be removed and the resource still exists), but this was a 
old design choice in the java model and clients are relying on this choice. 
Thus we cannot change this behavior. Sorry.