[ https://issues.jboss.org/browse/JBIDE-9934?page=com.atlassian.jira.plugin... ] Max Rydahl Andersen edited comment on JBIDE-9934 at 12/1/11 9:17 AM: --------------------------------------------------------------------- edited: this comment was talking about file permissions for chmod 0600 for ssh files - not related to this issue. was (Author: maxandersen): File f = ... // set f permission to correspond to 'chmod 0600' read/write only for user // First clear all permissions for both user and others f.setReadable(false, false); f.setWritable(false, false); // Enable only readable for user f.setReadable(true, true); f.setWritable(true, true); If you do the above in a different sequence you don't end up with chmod 0600. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBIDE-9934?page=com.atlassian.jira.plugin... ] Andre Dietisheim updated JBIDE-9934: ------------------------------------ Attachment: check-paths.patch @Max: please review -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBIDE-9934?page=com.atlassian.jira.plugin... ] Andre Dietisheim updated JBIDE-9934: ------------------------------------ Attachment: check-paths2.patch -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBIDE-9934?page=com.atlassian.jira.plugin... ] Andre Dietisheim edited comment on JBIDE-9934 at 12/8/11 1:21 PM: ------------------------------------------------------------------ there are 2 cases that cause things to fail: 1) There's a project in the workspace, that has the very same name as the name that's in the maven pom. The maven importer will then just refuse to import the OpenShift project. It will not throw an Exception but simply wont do anything. 2) the git clone destination folder already has a folder with the very same name as the OpenShift application. The current code would just overwrite that clone. 1) can only be handled correctly if we analyze the pom and find out about the maven name of the application. M5's too close to do that. I suggest that I simply watch the maven import and check if it imported anything. If not, I'll inform the user accordingly telling him that the maven import failed and the most obvious cause was an identical project in workspace. 2)should get handled by a warning/error marker on the git clone destination text-field and disable the finish button. M5's too close to do that. I suggest that we simply inform the user with a warning dialog telling him that the clone was not executed since it would have killed his prior checkout. was (Author: adietish): there are 2 cases that cause things to fail: 1) There's a project in the workspace, that has the very same name as the name that's in the maven pom. The maven importer will then just refuse to import the OpenShift project 2) the git clone destination folder already has a folder with the very same name as the OpenShift application. The current code would just overwrite that clone. 1) can only be handled correctly if we analyze the pom and find out about the maven name of the application. M5's too close to do that. I suggest that I simply watch the maven import and check if it imported anything. If not, I'll inform the user accordingly telling him that the maven import failed and the most obvious cause was an identical project in workspace. 2)should get handled by a warning/error marker on the git clone destination text-field and disable the finish button. M5's too close to do that. I suggest that we simply inform the user with a warning dialog telling him that the clone was not executed since it would have killed his prior checkout. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBIDE-9934?page=com.atlassian.jira.plugin... ] Max Rydahl Andersen updated JBIDE-9934: --------------------------------------- Attachment: JBIDE-9934.patch Had to reverse engineer the patch since it was not applying cleanly. In the end seemed to be mostly because of missing Exception classes and reformatting. I've applied the JBIDE-9934.patch to M5 - will open another jira for trunk to align. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBIDE-9934?page=com.atlassian.jira.plugin... ] Max Rydahl Andersen commented on JBIDE-9934: -------------------------------------------- applied to M5 so resolving. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira