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

Bug 354616

Summary: XtextBuilder 'blindspot' in Java change processing
Product: [Modeling] TMF Reporter: Vladimir Piskarev <vpiskarov>
Component: XtextAssignee: Project Inbox <tmf.xtext-inbox>
Status: CLOSED FIXED QA Contact:
Severity: minor    
Priority: P3 CC: sebastian.zarnekow
Version: 2.0.0   
Target Milestone: ---   
Hardware: All   
OS: All   
Whiteboard:
Attachments:
Description Flags
Sample language projects
none
'example' project none

Description Vladimir Piskarev CLA 2011-08-12 09:13:28 EDT 
Build Identifier: I20110613-1736

If Java changes happened before JavaChangeQueueFiller is initialized, XtextBuilder will not see them.

Reproducible: Always

Steps to Reproduce:
1. Import the attached 'org.xtext.example.domainmodel' and
'org.xtext.example.domainmodel.ui' projects into the workspace

2. Run the runtime workbench and import the attached 'example' project into the
runtime workspace

3. Close all Xtext editors (if some were open) and restart the runtime workbench

4. After restart, open 'Foo.java' and change 'Bar' to 'Baz'. Save the change. Note that 'Foo.dmodel' has not been rebuilt (there is
no error marker for it in Problems View).

Of course, it's a relatively minor issue (probably not seen too often in practice) and honestly, I don't know if it's even can be fixed (JDT does not provide something like ISavedState#processResourceChangeEvents), but nevertheless I decided to report it, just for the record.
Comment 1 Vladimir Piskarev CLA 2011-08-12 09:15:12 EDT 
Created attachment 201395 [details]
Sample language projects
Comment 2 Vladimir Piskarev CLA 2011-08-12 09:16:01 EDT 
Created attachment 201396 [details]
'example' project
Comment 3 Sebastian Zarnekow CLA 2011-08-15 11:24:38 EDT 
We could use a dummy extension on the JDT compiler extension point to ensure that the shared plugin gets activated.
Comment 4 Vladimir Piskarev CLA 2011-08-16 01:51:51 EDT 
I'm afraid that it may be a little too late a moment, because all POST_CHANGE listeners (including JDT DeltaProcessor) will have already been notified before the build happens (and a compilation participant gets activated).
Comment 5 Vladimir Piskarev CLA 2011-08-16 03:18:25 EDT 
Well, it seems I'm not quite right about this, because compilation participants also get activated on working copy reconcile. Whereas theoretically it is still not enough (there may be Java changes caused by resource synchronization, for example), it may be good enough solution in practice.
Comment 6 Sven Efftinge CLA 2012-11-23 02:31:15 EST 
We now have a compilation participant. Please reopen if that is not sufficient.
Comment 7 Eclipse Webmaster CLA 2017-10-31 10:47:06 EDT 
Requested via bug 522520.

-M.
Comment 8 Eclipse Webmaster CLA 2017-10-31 10:58:17 EDT 
Requested via bug 522520.

-M.