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

[John_Arthorne@xxxxxxx]

Stef, sorry for the lack of response.  It's not because we're ignoring you,
we just can't think of a good answer for your question.  By design,
builders are the recommended mechanism for performing work that has an
explicit ordering.  By configuring the build spec, you can specify the
temporal relationship between your builder and the java builder.  The
resource change listeners just don't have such an ordering mechanism.  We
could look into calling resource change listeners in plug-in prerequisite
order, but that is something we'd have to think about carefully before
commiting to anything.

Since you are dependent on java model changes, the java element deltas seem
to be the appropriate thing to be listening to.  As you said, this
mechanism is a bit limited because it doesn't allow resource changes during
the notification.

Given that there probably won't be radical changes to the listener
mechanism before 2.0, you're stuck with what's available for now.  One
thing you could try: listen to IJavaElementDeltas, collect the update
information, then create a thread that runs an IWorkspaceRunnable to
perform the updates.  This thread would block on the WorkspaceLock until
the workspace is open for updates, at which point it would be able to
changes resources, markers, etc.  This would essentially "post" the update
code to run after the previous operation completes.  This approach is less
than optimal, but it might just do the trick!




                                                                                                         
                    Stef_van_Dijk@xxxxxxx                                                                
                    Sent by:                         To:     platform-core-dev@xxxxxxxxxxx               
                    platform-core-dev-admin@e        cc:                                                 
                    clipse.org                       Subject:     [platform-core-dev] Model not updated  
                                                     in time                                             
                                                                                                         
                    12/17/2001 07:08 PM                                                                  
                    Please respond to                                                                    
                    platform-core-dev                                                                    
                                                                                                         
                                                                                                         




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
>>

_______________________________________________
platform-core-dev mailing list
platform-core-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/platform-core-dev