[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [platform-core-dev] Model not updated in time
|
Thanks for the response. I was asking for trouble by posting in late
December anyway. ;-)
As I described in one of the included messages, it's not the invocation of
the java builder which updates the java model. The model is not updated
until POST_CHANGE which occurs after all builders have run (including mine,
if I had one). Thus that is not a solution.
As for the java element deltas, that doesn't really help either for a
couple of reasons. First, it is far more useful for my plugin to know about
all affected resources. For example, if you modify a superclass, resource
change notification will tell me about changes to the .class files of any
subclasses that had to be recompiled. The java element deltas merely tell
me the .java file for the superclass was changed. Knowing about the
modified .class files is a key optimization for us. But again, the real
breaker is that the notification occurs at a time when I am unable to
perform the work I need, which is to update resource markers.
Your suggestion is an interesting one though. I could collect my validation
information from the resource change deltas during POST_CHANGE notification
and then block a thread on the WorkspaceLock. I'm not incredibly thread
programming literate and usually struggle when I have to do this sort of
thing. I don't suppose you have a simple example of how I would block a
thread on this WorkspaceLock, do you?
In any case, is there still time to consider a more optimal solution for
this problem in the 2.0 time frame?
Stef
John_Arthorne@xxxxxxx
Sent by: To: platform-core-dev@xxxxxxxxxxx
platform-core-dev-admin@e cc:
clipse.org Subject: Re: [platform-core-dev] Model not updated in
time
01/11/2002 12:11 PM
Please respond to
platform-core-dev
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!
