Closed liuhewei closed 9 years ago
Hey liuhewei!
Thanks for submitting this pull request! I'm here to inform the recipients of the pull request that you've already signed the CLA.
Minor suggestions on the new dialog:
@elsony Thans for your suggestion. I agree that a Question dialog is better in this scenario. We'll modified the code. update: the new message dialog is just like this:
We introduced an "Unmap Project" feature in 1.8.1. It's a reverse case, but it is still a workaround to handle the case where a user wants to delete a project but not the deployed application.
Steps for this are:
See comments here:
https://github.com/cloudfoundry/eclipse-integration-cloudfoundry/pull/23
This workaround does not replace the issue raised by this PR, but we also want to make sure we have a clean way to distinguish deleting a module when a Project is deleted vs other deleting cases aside from checking the module type to not be CloudFoundryApplicationModule and there is a bound project for that module.
We already have mechanism to delete modules without deleting the actual deployed application as used in the "Unmap Project" feature via a replace method in the CloudFoundryServer. See:
So it would now just be a question of cleanly determining that CloudFoundryServer.modifyModules(...) is being invoked on Project deletion only.
I've raised a separate issue to track this as the code base changed substantially to be able to merge this, and we already have another way of deleting modules without deleting the application that replaces the implementation in this PR
https://github.com/cloudfoundry/eclipse-integration-cloudfoundry/issues/37
Therefore I will close this PR, but still keep the issue open.
...ocal bound project
Currently:
Effect of the Modifications: