[ https://issues.jboss.org/browse/JBIDE-12826?page=com.atlassian.jira.plugi... ] Andre Dietisheim updated JBIDE-12826: ------------------------------------- Description: The new tooling (Beta1) now allows the user to use different servers which was not possible in prior releases. In prior releases the server that the tooling used was the server referenced in the express configurations (~/.openshift/express.conf and /etc/openshift/express.conf). There are preferences and project settings that we used in prior tooling that were referring to connections. When referring these values were only using the username (since there was no notion of a server). In the new tooling we should now allow referring to a server. We should not break old settings though. To do so we forsee the following strategies: * connection list (connection pool, that's also used by the OpenShift Explorer): The current key/values only use the username. Migration: * we keep the existing preference key/values * we create a new preference key * the connection pool is loading the old and new preferences * the connection pool is storing the connections that define connections to the default server to the old preferences * Project settings: The current entry is using the username only. Migration: * we keep the existing entry * we add a new entry if the user uses a connection to a custom (non-default) server * we update the old entry if the user changes the username was: The new tooling (Beta1) now allows the user to use different servers which was not possible in prior releases. In prior releases the server that the tooling used was the server referenced in the express configurations (~/.openshift/express.conf and /etc/openshift/express.conf). There are preferences and project settings that we used in prior tooling that were referring to connections. When referring these values were only using the username (since there was no notion of a server). In the new tooling we should now allow referring to a server. We should not break old settings though. To do so we forsee the following strategies: * connection list (connection pool, that's also used by the OpenShift Explorer): The current key/values only use the username. Migration: * we keep the existing preference key/values * we create a new preference key * the connection pool is loading the old and new preferences * the connection pool is storing the connections that define connections to the default server to the old preferences * Project settings: The current entry is using the username only. Migration: * we keep the existing entry * we add a new entry if the user uses a connection to a custom (non-default) server * we update the old entry if the user changes the username -- 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

[ https://issues.jboss.org/browse/JBIDE-12826?page=com.atlassian.jira.plugi... ] Andre Dietisheim updated JBIDE-12826: ------------------------------------- Description: The new tooling (Beta1) now allows the user to use different servers which was not possible in prior releases. In prior releases the server that the tooling used was the server referenced in the express configurations (~/.openshift/express.conf and /etc/openshift/express.conf). There are preferences and project settings that we used in prior tooling that were referring to connections. When referring these values were only using the username (since there was no notion of a server). In the new tooling we now allow referring to a server. We should not break old settings though. To do so we forsee the following strategies: * connection list (connection pool, that's also used by the OpenShift Explorer): The current key/values only use the username. Migration: ** we keep the existing preference key/values ** we create a new preference key ** the connection pool is loading the old and new preferences ** the connection pool is storing the connections that define connections to the default server to the old preferences * Project settings: The current entry is using the username only. Migration: ** we keep the existing entry ** we add a new entry if the user uses a connection to a custom (non-default) server ** we update the old entry if the user changes the username was: The new tooling (Beta1) now allows the user to use different servers which was not possible in prior releases. In prior releases the server that the tooling used was the server referenced in the express configurations (~/.openshift/express.conf and /etc/openshift/express.conf). There are preferences and project settings that we used in prior tooling that were referring to connections. When referring these values were only using the username (since there was no notion of a server). In the new tooling we should now allow referring to a server. We should not break old settings though. To do so we forsee the following strategies: * connection list (connection pool, that's also used by the OpenShift Explorer): The current key/values only use the username. Migration: ** we keep the existing preference key/values ** we create a new preference key ** the connection pool is loading the old and new preferences ** the connection pool is storing the connections that define connections to the default server to the old preferences * Project settings: The current entry is using the username only. Migration: ** we keep the existing entry ** we add a new entry if the user uses a connection to a custom (non-default) server ** we update the old entry if the user changes the username -- 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

[ https://issues.jboss.org/browse/JBIDE-12826?page=com.atlassian.jira.plugi... ] Andre Dietisheim edited comment on JBIDE-12826 at 10/10/12 7:46 AM: -------------------------------------------------------------------- My current understanding is that we only have the new values on a new workspace. Agree? was (Author: adietish): My current understanding is that we only have the new values on a new workspace. -- 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

[ https://issues.jboss.org/browse/JBIDE-12826?page=com.atlassian.jira.plugi... ] Max Rydahl Andersen commented on JBIDE-12826: --------------------------------------------- so its only in presence of the old keys we do this "approximation" ? works for me then. -- 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

[ https://issues.jboss.org/browse/JBIDE-12826?page=com.atlassian.jira.plugi... ] Stefan Bunciak commented on JBIDE-12826: ---------------------------------------- [~adietish]: Can you please provide some verification steps? For me it's just about that the wizard/explorer can connect to different openshift servers, am I right? -- 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

[ https://issues.jboss.org/browse/JBIDE-12826?page=com.atlassian.jira.plugi... ] Andre Dietisheim reassigned JBIDE-12826: ---------------------------------------- Assignee: Stefan Bunciak (was: Andre Dietisheim) -- 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

[ https://issues.jboss.org/browse/JBIDE-12826?page=com.atlassian.jira.plugi... ] Andre Dietisheim edited comment on JBIDE-12826 at 10/25/12 2:32 AM: -------------------------------------------------------------------- * project settings: The way to verify this is to work with a project, that you create in Alpha2 and work with it in Beta1. Alpha2 and Beta2 should both still work with the very same project. Alpha2 is only aware of the username, it would use the username (in the project settings) with the server that is defined in express.conf. Beta1 is aware of the username and a specific server that you configured. Beta1 would update the username (that Alpha1 is using) if you switch it in Beta1. * existing connections: This is not done yet (Beta1), see JBIDE-12909 was (Author: adietish): * project settings: The way to verify this is to work with a project, that you create in Alpha2 and work with it in Beta1. Alpha2 and Beta2 should both still work with the very same project. Alpha2 is only aware of the username, it would use the username (in the project settings) with the server that is defined in express.conf. Beta1 is aware of the username and server. Beta1 would update the username (that Alpha1 is using) if you switch it in Beta1. * existing connections: This is not done yet (Beta1), see JBIDE-12909 -- 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