[JBoss JIRA] (JBDS-3591) Publish JBDS on Windows Store
by Mickael Istria (JIRA)
Mickael Istria created JBDS-3591:
------------------------------------
Summary: Publish JBDS on Windows Store
Key: JBDS-3591
URL: https://issues.jboss.org/browse/JBDS-3591
Project: Developer Studio (JBoss Developer Studio)
Issue Type: Enhancement
Components: installer
Affects Versions: 10.0.0.Alpha1
Reporter: Mickael Istria
Priority: Optional
We should investigate the possibility of publishing JBDS on Windows Store to make installation from Windows more accessible.
That might also be worth it for the CDK installer.
cc [~akazakov] [~maxandersen]
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (JBIDE-21626) Pod is not created when docker image is deployed to OpenShift
by Marián Labuda (JIRA)
[ https://issues.jboss.org/browse/JBIDE-21626?page=com.atlassian.jira.plugi... ]
Marián Labuda commented on JBIDE-21626:
---------------------------------------
EXEC: Create a new projects 'project01' and 'project02'
ASSERT: Projects are empty, there are no OpenShift resources.
Scenario 1 - how oc works:
EXEC: From terminal run 'oc login' and login to the OpenShift instance.
EXEC: Fill in same credentials where 'project02' is created.
EXEC: Switch to project 'project02'.
EXEC: Run 'oc new-app openshift/hello-openshift'
RESULT: There are created a service, an image stream for docker image and a pod where the image is running.
You could also expose a service to get routing and show application in browser by running 'oc expose service hello-openshift', now you got also routing as you would have in tooling by checking the checkbox to create a route.
Scenario 2 - how OpenShift tooling works:
EXEC: On project 'project01' open context menu Deploy Docker Image... and search for image 'openshift/hello-openshift' and click next.
EXEC: Proceed through wizard and check checkbox to create a route for it and finish wizard.
RESULT: There is a service, a route and an image stream for docker image hello-openshift, but there is no pod for docker image.
EXPECTED RESULT: There is a service, a route and an image stream for docker image hello-openshift and also running pod. It is accessible via Show in browser and show 'Hello OpenShift!'
> Pod is not created when docker image is deployed to OpenShift
> -------------------------------------------------------------
>
> Key: JBIDE-21626
> URL: https://issues.jboss.org/browse/JBIDE-21626
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: openshift
> Affects Versions: 4.3.1.CR1
> Reporter: Marián Labuda
> Assignee: Jeff Cantrill
> Priority: Critical
> Labels: openshift_v3
> Fix For: 4.3.1.CR1
>
>
> When deploying a docker image to OpenShift via oc binary, pod where the image is supposed to run is created, together with service and router. But when deploying a docker image to OpenShift via OpenShift tools, no pod is created, only service and router. When using cli, pod is created later (what I noticed, there is different pull policy between creating from cli with "oc new-app docker-image" and creating from IDE).
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (JBIDE-21668) Fix collection setters in ResourcesUIModel
by Viacheslav Kabanovich (JIRA)
Viacheslav Kabanovich created JBIDE-21668:
---------------------------------------------
Summary: Fix collection setters in ResourcesUIModel
Key: JBIDE-21668
URL: https://issues.jboss.org/browse/JBIDE-21668
Project: Tools (JBoss Tools)
Issue Type: Enhancement
Components: openshift
Affects Versions: 4.4.0.Alpha1
Reporter: Viacheslav Kabanovich
Assignee: Jeff Cantrill
Fix For: 4.4.0.Alpha1
Collections setters in ResourcesUIModel, for instance
{code}
public void setBuildConfigs(Collection<IResourceUIModel> buildConfigs) {
firePropertyChange(PROP_BUILD_CONFIGS, resources.get(ResourceKind.BUILD_CONFIG), resources.put(ResourceKind.BUILD_CONFIG, new ArrayList<>(buildConfigs)));
}
{code}
fire incorrect newValue object, because java.util.Map.put(key, value) returns old object associated with the key, not the one just set.
At this moment, this does not create any bugs, because these setters are still not used, all changes go through ResourcesUIModel.add, ResourcesUIModel.remove, ResourcesUIModel.update that have correct notification. But bugs may appear as soon as collection setters are used, so that they better be fixed, for instance this way :
{code}
public void setBuildConfigs(Collection<IResourceUIModel> buildConfigs) {
setResourcesForKind(buildConfigs, ResourceKind.BUILD_CONFIG);
}
private void setResourcesForKind(Collection<IResourceUIModel> list, String kind) {
List<IResourceUIModel> oldList = resources.get(kind);
List<IResourceUIModel> newList = new ArrayList<IResourceUIModel>(list);
resources.put(kind, newList);
firePropertyChange(getProperty(kind), oldList, newList);
}
{code}
and with use of private setResourcesForKind all other setters will remain one-liners.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (JBIDE-21668) Fix collection setters in ResourcesUIModel
by Viacheslav Kabanovich (JIRA)
[ https://issues.jboss.org/browse/JBIDE-21668?page=com.atlassian.jira.plugi... ]
Viacheslav Kabanovich updated JBIDE-21668:
------------------------------------------
Description:
Created as follow up to JBIDE-21590.
Collections setters in ResourcesUIModel, for instance
{code}
public void setBuildConfigs(Collection<IResourceUIModel> buildConfigs) {
firePropertyChange(PROP_BUILD_CONFIGS, resources.get(ResourceKind.BUILD_CONFIG), resources.put(ResourceKind.BUILD_CONFIG, new ArrayList<>(buildConfigs)));
}
{code}
fire incorrect newValue object, because java.util.Map.put(key, value) returns old object associated with the key, not the one just set.
At this moment, this does not create any bugs, because these setters are still not used, all changes go through ResourcesUIModel.add, ResourcesUIModel.remove, ResourcesUIModel.update that have correct notification. But bugs may appear as soon as collection setters are used, so that they better be fixed, for instance this way :
{code}
public void setBuildConfigs(Collection<IResourceUIModel> buildConfigs) {
setResourcesForKind(buildConfigs, ResourceKind.BUILD_CONFIG);
}
private void setResourcesForKind(Collection<IResourceUIModel> list, String kind) {
List<IResourceUIModel> oldList = resources.get(kind);
List<IResourceUIModel> newList = new ArrayList<IResourceUIModel>(list);
resources.put(kind, newList);
firePropertyChange(getProperty(kind), oldList, newList);
}
{code}
and with use of private setResourcesForKind all other setters will remain one-liners.
was:
Collections setters in ResourcesUIModel, for instance
{code}
public void setBuildConfigs(Collection<IResourceUIModel> buildConfigs) {
firePropertyChange(PROP_BUILD_CONFIGS, resources.get(ResourceKind.BUILD_CONFIG), resources.put(ResourceKind.BUILD_CONFIG, new ArrayList<>(buildConfigs)));
}
{code}
fire incorrect newValue object, because java.util.Map.put(key, value) returns old object associated with the key, not the one just set.
At this moment, this does not create any bugs, because these setters are still not used, all changes go through ResourcesUIModel.add, ResourcesUIModel.remove, ResourcesUIModel.update that have correct notification. But bugs may appear as soon as collection setters are used, so that they better be fixed, for instance this way :
{code}
public void setBuildConfigs(Collection<IResourceUIModel> buildConfigs) {
setResourcesForKind(buildConfigs, ResourceKind.BUILD_CONFIG);
}
private void setResourcesForKind(Collection<IResourceUIModel> list, String kind) {
List<IResourceUIModel> oldList = resources.get(kind);
List<IResourceUIModel> newList = new ArrayList<IResourceUIModel>(list);
resources.put(kind, newList);
firePropertyChange(getProperty(kind), oldList, newList);
}
{code}
and with use of private setResourcesForKind all other setters will remain one-liners.
> Fix collection setters in ResourcesUIModel
> ------------------------------------------
>
> Key: JBIDE-21668
> URL: https://issues.jboss.org/browse/JBIDE-21668
> Project: Tools (JBoss Tools)
> Issue Type: Enhancement
> Components: openshift
> Affects Versions: 4.4.0.Alpha1
> Reporter: Viacheslav Kabanovich
> Assignee: Jeff Cantrill
> Fix For: 4.4.0.Alpha1
>
>
> Created as follow up to JBIDE-21590.
> Collections setters in ResourcesUIModel, for instance
> {code}
> public void setBuildConfigs(Collection<IResourceUIModel> buildConfigs) {
> firePropertyChange(PROP_BUILD_CONFIGS, resources.get(ResourceKind.BUILD_CONFIG), resources.put(ResourceKind.BUILD_CONFIG, new ArrayList<>(buildConfigs)));
> }
> {code}
> fire incorrect newValue object, because java.util.Map.put(key, value) returns old object associated with the key, not the one just set.
> At this moment, this does not create any bugs, because these setters are still not used, all changes go through ResourcesUIModel.add, ResourcesUIModel.remove, ResourcesUIModel.update that have correct notification. But bugs may appear as soon as collection setters are used, so that they better be fixed, for instance this way :
> {code}
> public void setBuildConfigs(Collection<IResourceUIModel> buildConfigs) {
> setResourcesForKind(buildConfigs, ResourceKind.BUILD_CONFIG);
> }
> private void setResourcesForKind(Collection<IResourceUIModel> list, String kind) {
> List<IResourceUIModel> oldList = resources.get(kind);
> List<IResourceUIModel> newList = new ArrayList<IResourceUIModel>(list);
> resources.put(kind, newList);
> firePropertyChange(getProperty(kind), oldList, newList);
> }
> {code}
> and with use of private setResourcesForKind all other setters will remain one-liners.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (JBIDE-21667) Make computing property names more conspicuous
by Viacheslav Kabanovich (JIRA)
[ https://issues.jboss.org/browse/JBIDE-21667?page=com.atlassian.jira.plugi... ]
Viacheslav Kabanovich updated JBIDE-21667:
------------------------------------------
Description:
Created as follow up to JBIDE-21590.
Property names of resources are computed in two places.
- From kind of resource in ResourcesUIModel:
{code}
private static String getProperty(String kind) {
return StringUtils.pluralize(kind.toLowerCase());
}
{code}
- From tab id in OpenShiftResourcePropertySection.setInput :
{code}
String property = org.apache.commons.lang.StringUtils.right(id, id.length() - id.lastIndexOf(".") - 1);
{code}
Maybe, there are more places that transform something to property name, I am not aware of them yet. But, imho, even if they are only 2 places and no other will appear, they are too much related to be separate and hidden in the depth of implementation. I suggest a utility that will encapsulate all manipulations with resource property names, (being in an internal package it may have public methods without getting into API), and describe in Java docs in details how it works. Tests for this utility may help to find early if some modification breaks consistency of related names.
was:
Property names of resources are computed in two places.
- From kind of resource in ResourcesUIModel:
{code}
private static String getProperty(String kind) {
return StringUtils.pluralize(kind.toLowerCase());
}
{code}
- From tab id in OpenShiftResourcePropertySection.setInput :
{code}
String property = org.apache.commons.lang.StringUtils.right(id, id.length() - id.lastIndexOf(".") - 1);
{code}
Maybe, there are more places that transform something to property name, I am not aware of them yet. But, imho, even if they are only 2 places and no other will appear, they are too much related to be separate and hidden in the depth of implementation. I suggest a utility that will encapsulate all manipulations with resource property names, (being in an internal package it may have public methods without getting into API), and describe in Java docs in details how it works. Tests for this utility may help to find early if some modification breaks consistency of related names.
> Make computing property names more conspicuous
> ----------------------------------------------
>
> Key: JBIDE-21667
> URL: https://issues.jboss.org/browse/JBIDE-21667
> Project: Tools (JBoss Tools)
> Issue Type: Enhancement
> Components: openshift
> Affects Versions: 4.4.0.Alpha1
> Reporter: Viacheslav Kabanovich
> Assignee: Jeff Cantrill
> Labels: code_quality
> Fix For: 4.4.0.Alpha1
>
>
> Created as follow up to JBIDE-21590.
> Property names of resources are computed in two places.
> - From kind of resource in ResourcesUIModel:
> {code}
> private static String getProperty(String kind) {
> return StringUtils.pluralize(kind.toLowerCase());
> }
> {code}
> - From tab id in OpenShiftResourcePropertySection.setInput :
> {code}
> String property = org.apache.commons.lang.StringUtils.right(id, id.length() - id.lastIndexOf(".") - 1);
> {code}
> Maybe, there are more places that transform something to property name, I am not aware of them yet. But, imho, even if they are only 2 places and no other will appear, they are too much related to be separate and hidden in the depth of implementation. I suggest a utility that will encapsulate all manipulations with resource property names, (being in an internal package it may have public methods without getting into API), and describe in Java docs in details how it works. Tests for this utility may help to find early if some modification breaks consistency of related names.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (JBIDE-21667) Make computing property names more conspicuous
by Viacheslav Kabanovich (JIRA)
Viacheslav Kabanovich created JBIDE-21667:
---------------------------------------------
Summary: Make computing property names more conspicuous
Key: JBIDE-21667
URL: https://issues.jboss.org/browse/JBIDE-21667
Project: Tools (JBoss Tools)
Issue Type: Enhancement
Components: openshift
Affects Versions: 4.4.0.Alpha1
Reporter: Viacheslav Kabanovich
Assignee: Jeff Cantrill
Fix For: 4.4.0.Alpha1
Property names of resources are computed in two places.
- From kind of resource in ResourcesUIModel:
{code}
private static String getProperty(String kind) {
return StringUtils.pluralize(kind.toLowerCase());
}
{code}
- From tab id in OpenShiftResourcePropertySection.setInput :
{code}
String property = org.apache.commons.lang.StringUtils.right(id, id.length() - id.lastIndexOf(".") - 1);
{code}
Maybe, there are more places that transform something to property name, I am not aware of them yet. But, imho, even if they are only 2 places and no other will appear, they are too much related to be separate and hidden in the depth of implementation. I suggest a utility that will encapsulate all manipulations with resource property names, (being in an internal package it may have public methods without getting into API), and describe in Java docs in details how it works. Tests for this utility may help to find early if some modification breaks consistency of related names.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (JBIDE-21658) Property sheet cells are editable
by Viacheslav Kabanovich (JIRA)
[ https://issues.jboss.org/browse/JBIDE-21658?page=com.atlassian.jira.plugi... ]
Viacheslav Kabanovich commented on JBIDE-21658:
-----------------------------------------------
[~maxandersen], [~adietish], please take a look at the pull request.
> Property sheet cells are editable
> ---------------------------------
>
> Key: JBIDE-21658
> URL: https://issues.jboss.org/browse/JBIDE-21658
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: openshift
> Affects Versions: 4.4.x
> Environment: Boss Openshift UI Plugin Version: 3.1.0.CR1-v20160202-0335-B166
> Reporter: Steve Speicher
> Attachments: Screen Shot 2016-02-06 at 9.03.05 AM.png
>
>
> When I bring up the property sheet, values are editable but I can't really edit them. It would be good if users were disallowed from changing values (like the property name field is restricted)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month