[ https://issues.jboss.org/browse/JBIDE-15357?page=com.atlassian.jira.plugi... ] Rob Stryker commented on JBIDE-15357: ------------------------------------- Eclipse/WTP: The JavaEEServerRefRefactorParticipant is in charge of removing the module from the server and initiating the publish operation. It should be publishing with dummy DeletedModule representations of the module that is in the process of being deleted, NOT the original. This is not currently happening. See also wtp classes: ProjectRefactoringListener, ProjectRefactorOperation.java JBT: Below are the various situations to be tested, and what their results are: 1) Close project + publish -> DeletedModule, and we ignore it 2) Close project + manual rm from server + publish -> DeletedModule, and we unpublish it 3) Delete project (not auto-remove fr. server) + publish -> DeletedModule, and we ignore it 4) Delete project (not auto-remove fr. server), then remove+publish -> DeletedModule, and we unpublish it 5) Delete project (w. auto-remove fr. server + auto-publish) -> (incorrect) RealModule, and we unpublish it For ASTools, situation 5 is the danger situation, and it is found to be safe after recent commits and tests. A related bug was found where our calculation of DeletedModule was incorrect. Affect on openshift: 1) openshift already throws coreexception if magic project is unaccessible (or deleted), so no change or error here 2) binary subprojects: a) openshift will currently delete any 'removed' module output file in magic project, regardless of whether it is real or DeletedModule b) openshift will currently "publish" any module that is not to be removed, regardless of whether it is a real module, DeletedModule,or incorrect non-DeletedModule that is missing. The effect of this is that {magicProject}/deployments/webProj.war will turn into an empty war file. So, openshift is already broken in this regard, and the change in ASTools will only affect it in that openshift will overwrite the binary file with an empty one during the delete operation directly instead of the 2nd publish. The user still has the opportunity to click "NO" in the "Do you want to commit" dialog, and so this bug is not critical. What this means is that OpenShift needs to adjust to not publish any DeletedModule NOT being removed, or any inaccessible project which is still 'deployed to' the server. The alternative is to make no commits on our side, recognize that a user must initiate a publish event manually after deleting the project to make the deployment go away. I do not vote for this solution currently. Finally, the class heirarchy of openshift really needs to stop inheriting stuff from ASTools, because the server structures are quite different. Hopefully, future refactors will make this easier. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira