[platform-core-dev] Model not updated in time

[Stef_van_Dijk@xxxxxxx]

It was suggested that the following discussion on jdt-core-dev might be
more appropriate here. I'm not totally sold on that, but I thought I'd let
you platform-core guys have a look at it anyway. The basic problem is that
I can't rely on a plugin (in this specific case, JDT Core) being completely
up-to-date until after POST_CHANGE. However, my plugin can't process the
resource change notifcation and add/remove markers as needed because the
resource tree is locked at this point.
I don't understand the JDT Core issues that prevent them from being
up-to-date before POST_CHANGE (say like after POST_AUTO_BUILD), but can
understand that any plugin might have such an implementation restriction.
So how can I, as a dependent plugin, do my work?
I understand the resource changes have to eventually come to an end, but
maybe there needs to be special consideration for being able to make
marker-only adjustments.

   Stef

>Stef,
>
> Any plugin A that needs the result of the resource delta processing done
by
> a plugin B would have the same problem. JDT cannot solve this problem. I
> think you should post your question to platform-core-dev.
>
> Jerome
>
>
>> We have encountered a situation which we haven't been able to get
around.
>> We currently listen to resource change notification on POST_AUTO_BUILD.
The
>> result is that the Java Model isn't fully up to date at this point. We
>> could change our logic to run on notification from the Java Model,
however
>> this currently won't work for us. The problem is that the Java Model is
>> being updated and signalling during POST_CHANGE resource change
>> notification, and the workspace is closed for change during notification
of
>> these events. Therefore while I can perform the necessary validations
>> successfully, I am not allowed to add/remove problem markers to/from
>> resources, which was the whole point of listening in the first place.
>>
>> It has been suggested that we should define a builder for this purpose.
The
>> builder would be registered as a post builder of the Java builder.
However,
>> I don't believe this will work. Since we are processing during
>> POST_AUTO_BUILD, we know the Java builder has already run. Looking at
the
>> code, the flow seems to be that the builders are all run,
POST_AUTO_BUILD
>> notification occurs (our code runs), POST_CHANGE notification occurs and
it
>> is at this point that the Java Model becomes up-to-date. Defining a
builder
>> would not appear to solve our problem.
>>
>>    Stef
>>