[jbosstools-issues] [JBoss JIRA] (JBIDE-11487) cleanup and align openshift settings exposed to users

[Rob Stryker (JIRA)]

    [ https://issues.jboss.org/browse/JBIDE-11487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12688645#comment-12688645 ] 

Rob Stryker commented on JBIDE-11487:
-------------------------------------

> Can't we just use the same UI and update the project settings with it ? 

I had considered this when I was making the change, but, no, we can't. The reason is because if you have two servers targeting the same project, imagine the following:

1) Create server 1 targeting project
2) Create server 2 targeting same project
3) Open editor 1, note deployment folder is "deployments"
4) Open editor 2, note the same
5) close editor 2
6) in editor 1, change deployments folder to "temp"
7) open editor 2, note that the deployments folder is now temp

Having the server editor modify the project settings will become very confusing for users trying to set up servers with different values. This is why anything editable by the server should be stored in the server, and vice versa. So allowing the server to change magic project is fine, because the server stores the magic project in the server settings. But allowing the user to change something which is stored in the project by using the editor will lead to inconsistancies and confusion. 

The only possible solutions here are to have project settings which can be overridden by the server, but not actually modify the project file.  The better solution of course is to make sure that settings that should be controlled by the server are stored in the server, while settings that are project-centric are stored on the project. 

It seems what we're requesting is to push the "remote" back into the server, and make it editable. The magic project is to be editable... and it seems we're not 100% in agreement what to do about the deployment folder. 
                
> cleanup and align openshift settings exposed to users
> -----------------------------------------------------
>
>                 Key: JBIDE-11487
>                 URL: https://issues.jboss.org/browse/JBIDE-11487
>             Project: Tools (JBoss Tools)
>          Issue Type: Bug
>          Components: openshift
>            Reporter: Max Rydahl Andersen
>            Assignee: Rob Stryker
>            Priority: Critical
>             Fix For: 3.3.0.Beta3
>
>
> From JBIDE-10527 I see that the following keys are stored in application servers:
> org.jboss.tools.openshift.express.internal.core.behaviour.ApplicationId="769fbce4ec324292938a7aca2d7cbb69" 
> org.jboss.tools.openshift.express.internal.core.behaviour.ApplicationName="app9" 
> org.jboss.tools.openshift.express.internal.core.behaviour.Domain="yourDomainHere" 
> org.jboss.tools.openshift.express.internal.core.behaviour.ExpressMode="publishSource" 
> org.jboss.tools.openshift.express.internal.core.behaviour.Username="username at example.com" 
> org.jboss.tools.openshift.express.internal.core.behaviour.binary.deployProject="app9"
> Two problems here:
> 1) the use of internal package names as base of the key - why is this not just openshift.<key> used as user visible setting ? Only if its something truly jboss tools specific could I see a reason to use a packagename, but still then not use internal since this key by the fact being stored in users settings are public and non-internal.
> 2) I think the project it self should be where applicationid, domain and usernme should be stored so the only thing the server needs to keep track of is deployProject and expressmode (if that is at all relevant anymore?)
> When creating servers you just then point to the project and get the info or select an application + project and the settings gets stored back on the project.
> That could be stored in .settings and be made available for tooling outside AS server integration. 

--
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