Re: [eclipse-dev] Want to understand how "language editor" plugins spawn

[David Karr <davidmichaelkarr@xxxxxxxxx>]

I've re-reviewed the "builders" doc and some of the related links.

It seems clear that I should implement a "YangNature" in addition to a "YangProjectBuilder".  The linked docs make the skeleton for this pretty simple.

In the project there is a "YangProjectWizard" class that extends "MavenProjectWizard", with a "performFinish()" method that does the work of actually creating the project.  I assume I would attach the "YangNature" at this point.

What's not so clear is exactly what I have do in the builder itself.  The docs cover the basic idea, but I'll have to figure out what existing mechanisms in the project I have to integrate this with.

To help understand what mechanisms are already in place, I set a breakpoint in the method and class that calls the Yang parser, and I noted the callstack when I hit this both on a "project clean" and making a trivial change to a file (without saving).

When I do a "project clean", I see classes like AutoBuildJob, BuildManager, MavenBuilder, MavenExecutionContext, and MavenBuilderImpl, followed by a "YangBuildParticipant" which extends "MojoExecutionBuildParticipant", with other project-specific classes including the call to the Yang parser at the top of the stack.

When I just make a change to a file, the same class is at the top of the stack, but the "ReconcilingStrategy" subclass is below that.  I've read some of the RS docs, so I know the basic idea of what that's for.

There is a ResourceChangeListener in effect, so it notices when I save file changes, but that doesn't result in any compiles (likely due to the lack of a Yang-specific builder).

Based on what I've described here, do you have any thoughts about what you might expect to see in that builder implementation?

On Fri, Dec 11, 2015 at 7:12 AM David Karr <davidmichaelkarr@xxxxxxxxx> wrote:

On Fri, Dec 11, 2015 at 6:23 AM Jonah Graham <jonah@xxxxxxxxxxxxxxxx> wrote:

Hi David,

I recommend you start with
https://eclipse.org/articles/Article-Builders/builders.html and see if
that answers your questions.

A quote from the summary: "The first of these is incremental project
builders, which create some built state based on the project contents,
and then keep that built state synchronized as the project contents
change"

Thanks Jonah (and Michael).

I've read about builders before, but I'll re-review this information with more focus.

The project the plugin creates already uses the Java and Maven builders.  I'll see if it makes sense to implement a special builder for this.

One thing that perplexes me a bit is that the Yang files in the project aren't even rebuilt when I save the project properties (like dependent projects).
 

On 10 December 2015 at 16:40, David Karr <davidmichaelkarr@xxxxxxxxx> wrote:
> This may seem like a "user" question, but I'm asking it here because I need
> to understand how some of the main Eclipse plugins work, so I can make a
> similar change.
>
> I've somewhat inherited a codebase for an Eclipse plugin that is used to
> view and edit source files in a somewhat obscure specification language.
> The plugin produces projects that are Maven Java projects, although the
> source files are not Java.  Not that it matters, but the files it edits are
> called "Yang" files.
>
> The plugin is pretty functionally complete for what it has to do, but it has
> one basic flaw.  It compiles the current Yang file well enough (using a
> parser from another open-source project) while in the editor, but the only
> time it compiles any other Yang files in the project, or in any project in
> the workspace, is if I load a particular Yang file in the editor, or if I do
> a "Project"->"Clean".
>
> This is an annoying issue, because Yang files can "import" other Yang files,
> and those imported Yang files can define types and other components that are
> referenced from "importing" Yang files. If I make a change in an "imported"
> Yang file and save it, I would expect the "importing" Yang file to
> immediately update based on that change.  For instance, if the importing
> file was referencing a field that would be defined in an imported file, but
> isn't defined yet, and I add that field to the imported file, the importing
> file should have a red mark immediately disappear.
>
> This is how Java editing works in Eclipse, and I really need this plugin to
> do the same thing.
>
> I've been examining the codebase for a few weeks now, and stepping through
> code in the debugger, but I'm realizing I need to understand how the "core"
> Eclipse plugins make this sort of thing happen.
>
> Can someone give me some advice on this?