bin/plugin should allow plugin files to be maintained for debugging purposes

[pickypg]

Currently, when unpacking plugin files, the files will be deleted in multiple scenarios (e.g., if it detects any *.java files) without a way to prevent it.

It would be ideal if there were a flag like --retain that could accompany --install (and the future --update) that would prevent the plugin manager from deleting the perceived-to-be extra--or particularly invalid--files. That way, plugin developers could themselves debug situations more easily and end users could see what the actual cause for the failure was.

The files should be retained in a special directory rather than in-place to avoid leaving files where they should not exist in the event that users do nothing with the retained files. It's worth considering whether to wholesale copy the original directory (extractLocation) into the special directory and then delete the actual files versus selectively moving the content that would otherwise be deleted.

As it currently exists, this pertains to the unpack function as it is currently implemented and modified in #5977.

[clintongormley]

@pickypg not quite understanding this issue... is this still something that you want? if so, could you explain more?

[pickypg]

#5977 (diff)

It related to how the PluginManager deletes everything, which seems pretty strict for any plugin developer that may be hitting issues with integration. Every step of unpacking the download results in deletions that may be hiding an issue.

It's certainly not a must-have flag.

[clintongormley]

@pickypg The part I don't understand is why the unpacking step requires so much debugging? Surely that's the easy bit. A developer will typically work with an unpacked plugin, no?

[pickypg]

True, I guess when I wrote the comment that I was thinking of autogenerated bundles failing. Since then, I think I've realized how unlikely that is. I will just got ahead and close this one. We can open it if it is ever an actual issue.