Bug 191962 - ElementChangedEvent not fired upon external modification
Summary: ElementChangedEvent not fired upon external modification
Status: RESOLVED INVALID
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 3.3   Edit
Hardware: PC Windows XP
: P3 normal (vote)
Target Milestone: 3.3 RC4   Edit
Assignee: Jerome Lanneluc CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-06-11 09:53 EDT by Hristo Sabev CLA
Modified: 2007-06-12 12:45 EDT (History)
0 users

See Also:

Attachments
JUnit Test Case reproducing the problem (6.12 KB, application/x-zip-compressed)
2007-06-12 11:10 EDT, Hristo Sabev CLA 		no flags Details
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Hristo Sabev CLA 2007-06-11 09:53:16 EDT 
Hi,

In our application we are using an external tool that generates java files in a given project. After the generation is finished we call javaProject.getResource().refreshLocal(IResource.DEPTH_INFINITE, null). This refreshesh the java model, however the necessary ElementChangedEvent-s are not broadcasted to the registered listeners. Calling the IOpenable.makeConsistent(IProgressMonitor) doesn't broadcast the events.

Regards,
Hristo
Comment 1 Hristo Sabev CLA 2007-06-11 10:30:53 EDT 
Hi,

One clarification. The external tool used the java.io.* API to create new files. It's exactly these new files for which ElementChangedEvent is not fired.

Regards,
Hristo
Comment 2 Jerome Lanneluc CLA 2007-06-11 10:37:07 EDT 
Could you please provide the build number and exact steps to reproduce ?
Comment 3 Hristo Sabev CLA 2007-06-12 11:06:30 EDT 
Hi,

I'm using Eclipse 3.3 RC1. JDT details:
Eclipse Java Development Tools
Version: 3.3.0.v20070501-0010-7o7hE8PEFpPomYYgh4CRhYP
Build id: I20070503-0010

Regards,
Hristo
Comment 4 Hristo Sabev CLA 2007-06-12 11:10:32 EDT 
Created attachment 71029 [details]
JUnit Test Case reproducing the problem

Hi,

In the attached file you can find a PDE JUnit test reproducing the problem. Check the assertions for definition of expected behavior.

Basically the test does the following:

1. Create a java project
2. Create source folder (package fragment root)
3. Creates a new compilation unit containing a primary type. This is done using the java.io API
4. Refreshesh the package fragment root with infinite depth
5. Verifies that no ElementChangedEvent with delta containing the newly created compilation unit has been fired. The delta is traveresed recursively through all the child deltas.

Regards,
Hristo
Comment 5 Jerome Lanneluc CLA 2007-06-12 12:22:04 EDT 
The first refresh causes a delta to be sent indicating that the package com.sap.test has been added. This implicitly include the addition of all children of the package.
No resource modification is done before the second refresh. So no delta is sent on the second refresh.

This works as designed.
Comment 6 Hristo Sabev CLA 2007-06-12 12:45:44 EDT 
Hi,

Thanks for the clarification.

Regards,
Hristo