Home » Language IDEs » Java Development Tools (JDT) » Building in response to .java file changes
Building in response to .java file changes [message #250828] |
Wed, 23 January 2008 03:16 ![Go to next message Go to next message](theme/Solstice/images/down.png) |
Eclipse User![Friend of Eclipse Friend](/donate/web-api/friends_decorator.php?email=) |
|
|
|
Originally posted by: rob.brainkandy-dot-org.org
Hello,
Long series of questions ahead, sorry. I've been working on parts of this
problem for several months, and I have been avoiding this component for a while,
because there are some parts to the problem that I just can't get my head
around. This is in-part a platform question, but since most of it has a
JDT-bent, I thought I'd start here.
I want to maintain a local cache of interesting information in a project. When a
..java file changes (or is added), I want to parse the AST, find some specific
IJavaElement objects, and store them in an in-memory cache for easy access.
Assume for the sake of discussion, this is stored in a Map<IFile,
Set<IJavaElement>> (henceforth called 'map'.)
Note: these IJavaElement objects are not necessarily children of the IFile's
ICompilationUnit.
I'm planning to write either a resource listener or a Builder. It could be
either, but to keep this email clear, I'll just say it's a Builder.
Here are my questions and assumptions:
1. I assume that shutting down Eclipse initiates a close-workspace operation.
and starting Eclipse initiates an open-workspace operation. Also I assume that
using the Switch Workspace UI command initiates the same close-workspace
operation followed by the same open-workspace operation. Am I right, and if so,
how do I register a listener for these events?
2. If I want to cache map, either by
* storing the whole map as a project property, or
* individually as per-file properties, or
* storing it as a derived resource
How do I store an IJavaElement so it can be serialized and reloaded as quickly
as possible?
Alternatively, I could choose to not serialize map, and rebuild it when the
workspace listener hears about the open-workspace operation.
3. What is a good strategy for ensuring that when my Builder learns about
changes in .java files, it's parsing an AST and resolving bindings that are
up-to-date, and don't refer to the state of the compiled project before these
..java files changed?
I suspect what I want is to wait until the JavaBuilder completes before my
Builder even triggers its build command. Is this reasonable? Is it possible? Is
it better for me to have a Builder that listens to changes in generated .class
files, and use that as the impetus for building my map? Or should I write an
IElementChangedListener, and dump the Builder altogether?
Thanks. I hope these questions are clear. I could have asked each of them
separately, making them more likely to be asked, but then you would lose context.
Robert
|
|
|
Re: Building in response to .java file changes [message #250973 is a reply to message #250828] |
Sun, 27 January 2008 18:19 ![Go to previous message Go to previous message](theme/Solstice/images/up.png) |
Alex Le![Friend of Eclipse Friend](/donate/web-api/friends_decorator.php?email=unbonnevie%40yahoo.com) Messages: 649 Registered: July 2009 |
Senior Member |
|
|
Robert Konigsberg wrote:
>
> I want to maintain a local cache of interesting information in a
> project. When a .java file changes (or is added), I want to parse the
> AST, find some specific IJavaElement objects, and store them in an
> in-memory cache for easy access. Assume for the sake of discussion, this
> is stored in a Map<IFile, Set<IJavaElement>> (henceforth called 'map'.)
>
> Note: these IJavaElement objects are not necessarily children of the
> IFile's ICompilationUnit.
>
> I'm planning to write either a resource listener or a Builder. It could
> be either, but to keep this email clear, I'll just say it's a Builder.
>
> Here are my questions and assumptions:
>
> 1. I assume that shutting down Eclipse initiates a close-workspace
> operation. and starting Eclipse initiates an open-workspace operation.
> Also I assume that using the Switch Workspace UI command initiates the
> same close-workspace operation followed by the same open-workspace
> operation. Am I right, and if so, how do I register a listener for these
> events?
Don't forget also when a user closes/deletes a project, thus all of its
children resources, or when a user deletes an IResource (IFolder/IFile)
contained by a project/folder. Same thing for adding/renaming
resources. Then you have update your cache accordingly, e.g., removing
invalid entries.
Yes, your builder should also be notified on such events. You might
have to register a listener via the ResourcesPlugin if you want to react
to the event in a PRE-manner, that is, BEFORE eclipse actually performs
the change. There is a PRE/POST event. Eclipse will tell exactly all
the information you need via a delta change of resource. From there
your visitor can visit the delta (a tree) and performs whatever needed
for each of the element(s) in the delta change.
>
> 2. If I want to cache map, either by
> * storing the whole map as a project property, or
> * individually as per-file properties, or
> * storing it as a derived resource
If you want persistency, store in a hidden preference entry, assuming an
IResource's properties are not persisted by Eclipse. If so, that is even
better.
I would use properties rather than derived resource and I would use as
per project rather than per-file, since that would be consistent with
the tree organization of resources in the workspace. The more scattered
the information, the more bookkeeping you will have to do.
> How do I store an IJavaElement so it can be serialized and reloaded as
> quickly as possible?
>
Serialized as XML? POJO?
In the past I had done the above in a configuration manner but not a
cache, both as properties, for example, having a project referenced
another project. I had also use POJO to stored serialized info in
dotted file in a project and not showing it. Then I had to write a hook
(using one of the model extension points) to make sure NOT to allow the
user deleting the dotted file in the project.
> Alternatively, I could choose to not serialize map, and rebuild it when
> the workspace listener hears about the open-workspace operation.
>
> 3. What is a good strategy for ensuring that when my Builder learns
> about changes in .java files, it's parsing an AST and resolving bindings
> that are up-to-date, and don't refer to the state of the compiled
> project before these .java files changed?
>
> I suspect what I want is to wait until the JavaBuilder completes before
> my Builder even triggers its build command. Is this reasonable? Is it
> possible? Is it better for me to have a Builder that listens to changes
> in generated .class files, and use that as the impetus for building my
> map? Or should I write an IElementChangedListener, and dump the Builder
> altogether?
>
> Thanks. I hope these questions are clear. I could have asked each of
> them separately, making them more likely to be asked, but then you would
> lose context.
>
> Robert
|
|
|
Goto Forum:
Current Time: Thu Aug 15 02:30:48 GMT 2024
Powered by FUDForum. Page generated in 0.04631 seconds
|