Default Pinned Zowe UI Plugins

[MarkAckert]

@hogstrom @armstro @1000TurquoisePogs @jplinardon @stevenhorsman-ibm @nkocsis

Could the ZLC please review and vote by EOD 9/25 - the Zowe UI now defines a JSON file which will track pinned plugins on the Zowe UI taskbar. This JSON file does not, by default, contain the explorer-server plugins, but you can still reach these plugins through the "Start" menu on the bottom left of the UI and pin them from there.

Is the new behavior described above desirable or should we add scripts to the install process which set explorer-server plugins as pinned (via modifying the new JSON)?

[1000TurquoisePogs]

So, this is about dev vs shipping, and not breaking either. It is desirable to have pinned plugins, but the list of pinned plugins should vary dependent upon purpose of the deliverable. The explorer plugins should be pinned, but I think this should be done as a packaging-time or install-time task, and here's why:

Correct me if I'm wrong, but I believe that the explorer Apps have a different dev install procedure from other Apps, which is hidden by the good install script we have in the pax we provide. The current dev use of ZLUX is to just go into zlux-build and run build.sh / build.bat. The zlux-test-server repo has some default settings dependent upon the expected behavior that results from running zlux-build/build.sh

So, since that doesn't currently set up the explorer server, the explorer Apps are not part of that default pinned plugins list.

However:

1. I see no reason why a pax should respect this... If you have a package of Zowe components, the installation procedure of them should be shipping or dynamically constructing a totally new pinned plugins list based on what is in the pax, and what the pax-makers want to be the defaults. Imagine if you had a 'zowe for graphic designers' (silly hypothetical)... you'd want to set a default to pin some graphic designing plugins, while leaving word processing and code editing plugins unpinned.

2. If zlux-build did also set up the explorer servers, or if devs depended upon some script that did a combination of explorer & zlux-build building, then it would be fine to put the explorers as pinned plugins in zlux-example-server

The whole 'pinned plugins' feature takes advantage of the configuration dataservice which allows product defaults, administrative defaults, and user preferences. So, what we want to do is have the appropriate product defaults which is primarily a packaging-time task.

[stevenhorsman]

Hey @1000TurquoisePogs - just to clarify (though it's probably me that confused), the proposal is that we add something in to the explorer install apps (the thing that created the plugins for zlux) which also add them to the pinnedPlugins.json. We aren't suggesting that the default in zlux should be changed, just raising the questions of whether we should add the explorers to it when we install them. I hope this helps.

[1000TurquoisePogs]

Whether you should be allowed to do that depends on if its for dev, or for end users.

For end users, plugins shouldn't have that authority. Plugins shouldn't by able to tell the server to pin them. Instead, product, administrator, or user settings should be the determination. So for building a pax, the set of build tools should be involved in making that pinnedPlugins.json

However, for developers, it's fine if one of the explorer repos has some dev scripts that copy/modify pinnedPlugins.json.

[MarkAckert]

To clarify what's been said here for myself - I think we're in agreement on how to set default pins for the Zowe PAX. We make modifications to the pinnedPlugins.json file as part of our installation script suite within the PAX file. This avoids plugins gaining control over the pinnedPlugins directly, and keeps the base zlux pinnedPlugins.json clean.

[armstro]

So I am woefully behind on various emails/slack communications - please tolerate some dumb questions as I try to catch up........there was a request for a vote on having the explorers pinned to the desktop - did we decide that we would add the explorers (at least for open beta)? Is a vote needed?

Bruce Armstrong IBM System Z Offering Manager- zowe.org 4205 S MIAMI BLVD, DURHAM NC 27703-9141 Email: armstrob@us.ibm.com Tel: 919-254-8773 Cell: 919-931-3132

From: Sean Grady notifications@github.com To: zowe/zlc zlc@noreply.github.com Cc: armstro armstrob@us.ibm.com, Mention mention@noreply.github.com Date: 09/24/2018 10:42 AM Subject: Re: [zowe/zlc] Default Pinned Zowe UI Plugins (#39)

So, this is about dev vs shipping, and not breaking either. It is desirable to have pinned plugins, but the list of pinned plugins should vary dependent upon purpose of the deliverable. The explorer plugins should be pinned, but I think this should be done as a packaging-time or install-time task, and here's why: Correct me if I'm wrong, but I believe that the explorer Apps have a different dev install procedure from other Apps, which is hidden by the good install script we have in the pax we provide. The current dev use of ZLUX is to just go into zlux-build and run build.sh / build.bat. The zlux-test-server repo has some default settings dependent upon the expected behavior that results from running zlux-build/build.sh So, since that doesn't currently set up the explorer server, the explorer Apps are not part of that default pinned plugins list. However:

1. I see no reason why a pax should respect this... If you have a package of Zowe components, the installation procedure of them should be shipping or dynamically constructing a totally new pinned plugins list based on what is in the pax, and what the pax-makers want to be the defaults. Imagine if you had a 'zowe for graphic designers' (silly hypothetical)... you'd want to set a default to pin some graphic designing plugins, while leaving word processing and code editing plugins unpinned.
2. If zlux-build did also set up the explorer servers, or if devs depended upon some script that did a combination of explorer & zlux-build building, then it would be fine to put the explorers as pinned plugins in zlux-example-server The whole 'pinned plugins' feature takes advantage of the configuration dataservice which allows product defaults, administrative defaults, and user preferences. So, what we want to do is have the appropriate product defaults which is primarily a packaging-time task. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[hogstrom]

This issue was moved to zowe/explorer-utilities#3

[hogstrom]

Moved here (not sure if its the correct repo, but this issue is for the Explorer team to implement.