[
https://issues.jboss.org/browse/JBIDE-11487?page=com.atlassian.jira.plugi...
]
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(a)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