Add Generate Build File and Refresh actions

[SanjulaGanepola]

⚠️Please review and merge #83 first and then rebase this PR as this one builds on top of it⚠️

Changes

• Add Refresh action to both impact views
• Add imd build file generation support to server
• Add Generate Build File inline submenu with options for Bob, Make, Impact Report, and JSON Report

@worksofliam Do you have a better name for the JSON Report or is this alright?

[edmundreinhardt]

what about this new imd thing?

[SanjulaGanepola]

Good catch. I will add that here.

@worksofliam How are these tasks run? Are these something that should be in the list of runnable tasks?

[edmundreinhardt]

Why don't you want to delay until there is a SourceOrbit project loaded?

[SanjulaGanepola]

Rather than hiding the view, I think it made more sense to always have the view visible and use welcome text.

[edmundreinhardt]

Should we somehow indicated that these are "Affected IBM i Objects"
This view will popup when the user is doing unrelated things now, they may open a Java files and not see "affected objects"

[SanjulaGanepola]

Good point. Renaming the view would make sense or updating the welcome text to also say "...affected IBM i objects"

@worksofliam Any thoughts on the visibility of this view?

[worksofliam]

@SanjulaGanepola I do think giving it more context with a name like 'Affected IBM i objects' is better. We should do that in this PR.

We aren't going to do this: but for context, a typical way to handle multiple views and ensure they belong to the same group (like IBM i) is use a panel, so then, when the view is moved by the user to another panel (like explorer or scm) then the title becomes 'IBM i: Affected Objects'.

[SanjulaGanepola]

@worksofliam Updated the text: 1294f4b

As for moving the view outside where it typically belongs, I do see that a contextualTitle was already added to both views which is rendered instead of the panel name:

• Active Editor: Source Impacts
• Source Changes: Change Impacts

Keep as is? Change to IBM i: ...? Change to Source Orbit: ...?

[SanjulaGanepola]

If no change is needed, looks good to merge 😃

[worksofliam]

@SanjulaGanepola Let's get this branch cleaned up with the latest commits and then I will get to review today. Thanks!

[SanjulaGanepola]

@worksofliam PR is ready for review

[worksofliam]

So most of these changes are specifually for the Project Explorer UI. I think a majorty of the new commands make sense and I am happy with them, but I don't think our package.json file should be referencing projectExplorer. Of course, these aren't hard dependencies on Project Explorer, but it becomes soft-circular when we do this.

I personally think any reference to projectExplorer in package.json should be removed (notably the new submenu entry and item/context item) and instead should be added in the Project Explorer extension.

Other than that, a lot of this makes sense to me.

[SanjulaGanepola]

I personally think any reference to projectExplorer in package.json should be removed (notably the new submenu entry and item/context item) and instead should be added in the Project Explorer extension.

The problem is that Project Explorer does not include Source Orbit as a hard dependency. This means that moving these commands to PE's package.json would break it when Source Orbit is not installed (unless we wrapper these same commands with PE commands).

Also, does it make sense for the tree items to be coming from the Source Orbit extension, but the command contributions are coming from PE?

What do you think?

[worksofliam]

@SanjulaGanepola on second thought, as long as this PR doesn't add a hard dependency on anything (like PE) then I think it will be ok.

Sound ok?

[SanjulaGanepola]

Yup I agree no hard dependency is the way to go. It should work with or without PE installed

[worksofliam]

I think we're almost done. Minor details now.

I do think giving it more context with a name like 'Affected IBM i objects' is better. We should do that in this PR.