[JBoss JIRA] (JBDS-2733) Make Cordova tooling and CordovaSim ready to be available from software/update tab
by Max Rydahl Andersen (JIRA)
[ https://issues.jboss.org/browse/JBDS-2733?page=com.atlassian.jira.plugin.... ]
Max Rydahl Andersen edited comment on JBDS-2733 at 10/24/13 3:44 AM:
---------------------------------------------------------------------
so we closed JBDS-2733 too soon. It was not actually added to central as found in JBDS-2812 ;/
was (Author: maxandersen):
so we closed JBDS-2812 too soon. It was not actually added to central ;/
> Make Cordova tooling and CordovaSim ready to be available from software/update tab
> -----------------------------------------------------------------------------------
>
> Key: JBDS-2733
> URL: https://issues.jboss.org/browse/JBDS-2733
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: aerogear-hybrid, requirements
> Reporter: Burr Sutter
> Assignee: Max Rydahl Andersen
> Fix For: 7.1.0.Beta1
>
>
> Cordova should be available from JBDS, but it is not fully supported tech yet thus should be included/marked as a Technology Preview
--
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
12 years, 8 months
[JBoss JIRA] (JBIDE-15771) Duplicate and missing menu item for Markers
by Marián Labuda (JIRA)
Marián Labuda created JBIDE-15771:
-------------------------------------
Summary: Duplicate and missing menu item for Markers
Key: JBIDE-15771
URL: https://issues.jboss.org/browse/JBIDE-15771
Project: Tools (JBoss Tools)
Issue Type: Bug
Components: openshift
Affects Versions: 4.1.1.Beta1
Reporter: Marián Labuda
Assignee: Andre Dietisheim
There are 2 menu items for "Configure Markers..." in Project explorer context menu of the project and in the Package explorer is missing menu item for "Configure Markers..." see attached image.
--
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
12 years, 8 months
[JBoss JIRA] (JBIDE-15766) openshift-java-client: dont refresh env variables on each addition/removal
by Martes Wigglesworth (JIRA)
[ https://issues.jboss.org/browse/JBIDE-15766?page=com.atlassian.jira.plugi... ]
Martes Wigglesworth edited comment on JBIDE-15766 at 10/24/13 12:46 AM:
------------------------------------------------------------------------
When attempting to use solutions I., and II. in the previously listed solution analysis, I became aware of the fact that none of the integration tests will pass without this update feature called at the end of each operation referenced.
There is no internal aspect that refreshes the list, so for now, it seems that the only option, without referencing option IV., is to refer to option III. and leave it as is.
There does not seem to be any simple way to update the components each time that we add or remove from the list in the backend.
I.E.
When we need to remove the a variable, we don't actually alter the object collection on the plugin side, when the operation is concluded. So when we destroy a variable, the IEnvironmentVariable instance is still alive on this side, instead of being removed already. The way this is resolved currently, is that the Collection is repopulated with the current pull from the back-end, using the update... methods being referenced in this JIRA issue.
The methods calls can be removed, however, only with further investigation.
Until we do the extra cleanup, we will need to keep these method calls in place.
was (Author: mwigglesworth-redhat):
Technically I can resolve this issue by removing the update call from both add, and remove, hence forcing the refresh to be called explicitly.
Is this behaviour desirable?
> openshift-java-client: dont refresh env variables on each addition/removal
> --------------------------------------------------------------------------
>
> Key: JBIDE-15766
> URL: https://issues.jboss.org/browse/JBIDE-15766
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: openshift
> Affects Versions: 4.1.1.Beta1, 4.2.0.Alpha1
> Reporter: Andre Dietisheim
> Assignee: Andre Dietisheim
> Fix For: 4.1.1.Beta1, 4.2.0.Alpha1
>
>
> When adding/removing environment variables, the openshift-java-client would always request the backend for the full list. This should not be required and avoided
> {code:title=ApplicationResource#addEnvironmentVariable}
> EnvironmentVariableResourceDTO environmentVariableResourceDTO =
> new AddEnvironmentVariableRequest().execute(name, value);
> IEnvironmentVariable environmentVariable = new EnvironmentVariableResource(environmentVariableResourceDTO, this);
> updateEnvironmentVariables();
> return environmentVariable;
> {code}
> {code:title=ApplicationResource#updateEnvironmentVariables}
> protected void updateEnvironmentVariables() throws OpenShiftException {
> if (environmentVariableByName == null) {
> environmentVariableByName = loadEnvironmentVariables();
> } else {
> environmentVariableByName.clear();
> environmentVariableByName.putAll(loadEnvironmentVariables());
> }
> }
> {code}
--
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
12 years, 8 months
[JBoss JIRA] (JBIDE-15766) openshift-java-client: dont refresh env variables on each addition/removal
by Martes Wigglesworth (JIRA)
[ https://issues.jboss.org/browse/JBIDE-15766?page=com.atlassian.jira.plugi... ]
Martes Wigglesworth edited comment on JBIDE-15766 at 10/24/13 12:38 AM:
------------------------------------------------------------------------
Use Cases:
Add
1) add non-existing variable
2) add pre-existing variable
Remove
1) remove pre-existing variable
2) remove non-pre-existing variable
Solution analysis:
I. Simply remove the update operations from both the add and remove methods listed.
II. Remove update from remove, and leave it in add
III. Leave update in both aspects due to massive rework requirement.
IV. Alter the current behaviours of the add and remove operations as follows:
a) The update should be removed from add and remove because nothing is actually done with the updated list, other than to make sure that the list is updated.
i)In the case that the add operation is successful, then your local variable list will simply reflect the remote list. The add method should then return boolean "true" based on the outcome of the operation.
ii)In the case that the add operation is not successful, then the add operation should capture the exception and return a boolean indication. The add method should then return boolean "false" based on the outcome of the operation.
iii)In the case for the remove operation, if the removal is successful, the list should already reflect the external list, and does not need to be updated. The remove method should then return boolean "true" based on the outcome of the operation.
iv) In the case for the remove operation that is not successful, a boolean of false should be rendered, and the list would still reflect the removed variable anyhow. The remove method should then return boolean "false" based on the outcome of the operation.
v) In all of the cases listed above, a side-effect update to the list is not really needed to complete the operations on the incident variable list, hence it should be removed in this solution option as well.
b) There may be a possibility of a race condition in 2.0, according to Jay, so we will need to build some further robustness into these operations.
I propose that we change the add and remove operations to be dependent upon exceptions being generated for operations such as add, remove/destroy, such that indicators for the results on remove and add operations are returned to the user of the plugin.
This may be further than the scope of this issue, however, I am not sure. During initial testing for this functionality in the destroy() integration tests, I could not generate an exception based on reuse of an instance of IEnvironmentVariable retrieved from the IApplication instance, and using IEnvironmentVariable.destroy() twice. No exception is generated when you call the operation.
A lack of understanding of how the destroy() method is supposed to work may have been the reason that I was unable to generate the assumed to be available SSHOperationException.
However, are the service objects supposed to generate an exception when you attempt to remove a variable that does not exist? (Answer: It currently does not due to the flow of the application processing.)
was (Author: mwigglesworth-redhat):
Use Cases:
Add
1) add non-existing variable
2) add pre-existing variable
Remove
1) remove pre-existing variable
2) remove non-pre-existing variable
Solution analysis:
I. Simply remove the update operations from both the add and remove methods listed.
II. Remove update from remove, and leave it in add
III. Alter the current behaviours of the add and remove operations as follows:
a) The update should be removed from add and remove because nothing is actually done with the updated list, other than to make sure that the list is updated.
i)In the case that the add operation is successful, then your local variable list will simply reflect the remote list. The add method should then return boolean "true" based on the outcome of the operation.
ii)In the case that the add operation is not successful, then the add operation should capture the exception and return a boolean indication. The add method should then return boolean "false" based on the outcome of the operation.
iii)In the case for the remove operation, if the removal is successful, the list should already reflect the external list, and does not need to be updated. The remove method should then return boolean "true" based on the outcome of the operation.
iv) In the case for the remove operation that is not successful, a boolean of false should be rendered, and the list would still reflect the removed variable anyhow. The remove method should then return boolean "false" based on the outcome of the operation.
v) In all of the cases listed above, a side-effect update to the list is not really needed to complete the operations on the incident variable list, hence it should be removed in this solution option as well.
b) There may be a possibility of a race condition in 2.0, according to Jay, so we will need to build some further robustness into these operations.
I propose that we change the add and remove operations to be dependent upon exceptions being generated for operations such as add, remove/destroy, such that indicators for the results on remove and add operations are returned to the user of the plugin.
This may be further than the scope of this issue, however, I am not sure. During initial testing for this functionality in the destroy() integration tests, I could not generate an exception based on reuse of an instance of IEnvironmentVariable retrieved from the IApplication instance, and using IEnvironmentVariable.destroy() twice. No exception is generated when you call the operation.
A lack of understanding of how the destroy() method is supposed to work may have been the reason that I was unable to generate the assumed to be available SSHOperationException.
However, are the service objects supposed to generate an exception when you attempt to remove a variable that does not exist?
> openshift-java-client: dont refresh env variables on each addition/removal
> --------------------------------------------------------------------------
>
> Key: JBIDE-15766
> URL: https://issues.jboss.org/browse/JBIDE-15766
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: openshift
> Affects Versions: 4.1.1.Beta1, 4.2.0.Alpha1
> Reporter: Andre Dietisheim
> Assignee: Andre Dietisheim
> Fix For: 4.1.1.Beta1, 4.2.0.Alpha1
>
>
> When adding/removing environment variables, the openshift-java-client would always request the backend for the full list. This should not be required and avoided
> {code:title=ApplicationResource#addEnvironmentVariable}
> EnvironmentVariableResourceDTO environmentVariableResourceDTO =
> new AddEnvironmentVariableRequest().execute(name, value);
> IEnvironmentVariable environmentVariable = new EnvironmentVariableResource(environmentVariableResourceDTO, this);
> updateEnvironmentVariables();
> return environmentVariable;
> {code}
> {code:title=ApplicationResource#updateEnvironmentVariables}
> protected void updateEnvironmentVariables() throws OpenShiftException {
> if (environmentVariableByName == null) {
> environmentVariableByName = loadEnvironmentVariables();
> } else {
> environmentVariableByName.clear();
> environmentVariableByName.putAll(loadEnvironmentVariables());
> }
> }
> {code}
--
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
12 years, 8 months
[JBoss JIRA] (JBIDE-15770) Can't remove cordova plugins with "remove cordova plugin" menu item
by Michelle Murray (JIRA)
Michelle Murray created JBIDE-15770:
---------------------------------------
Summary: Can't remove cordova plugins with "remove cordova plugin" menu item
Key: JBIDE-15770
URL: https://issues.jboss.org/browse/JBIDE-15770
Project: Tools (JBoss Tools)
Issue Type: Bug
Components: aerogear-hybrid
Affects Versions: 4.1.1.Beta1
Reporter: Michelle Murray
"Remove Cordova plugin" menu item doesn't work.
1. Make a hybrid mobile project with wizard
2. Add a cordova plugin via the Cordova Configuration Editor, Platform Properties pane, Add button >> plug-ins listed in Project Explorer tab under plugins folder
4. Right-click plug-in name (in Project Explorer)
5. Click Remove Cordova Plugin >> window flashes open and closes immediately, plug-in still listed under plugin folder :(
--
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
12 years, 8 months
[JBoss JIRA] (JBIDE-15766) openshift-java-client: dont refresh env variables on each addition/removal
by Martes Wigglesworth (JIRA)
[ https://issues.jboss.org/browse/JBIDE-15766?page=com.atlassian.jira.plugi... ]
Martes Wigglesworth edited comment on JBIDE-15766 at 10/23/13 11:12 PM:
------------------------------------------------------------------------
Use Cases:
Add
1) add non-existing variable
2) add pre-existing variable
Remove
1) remove pre-existing variable
2) remove non-pre-existing variable
Solution analysis:
I. Simply remove the update operations from both the add and remove methods listed.
II. Remove update from remove, and leave it in add
III. Alter the current behaviours of the add and remove operations as follows:
a) The update should be removed from add and remove because nothing is actually done with the updated list, other than to make sure that the list is updated.
i)In the case that the add operation is successful, then your local variable list will simply reflect the remote list. The add method should then return boolean "true" based on the outcome of the operation.
ii)In the case that the add operation is not successful, then the add operation should capture the exception and return a boolean indication. The add method should then return boolean "false" based on the outcome of the operation.
iii)In the case for the remove operation, if the removal is successful, the list should already reflect the external list, and does not need to be updated. The remove method should then return boolean "true" based on the outcome of the operation.
iv) In the case for the remove operation that is not successful, a boolean of false should be rendered, and the list would still reflect the removed variable anyhow. The remove method should then return boolean "false" based on the outcome of the operation.
v) In all of the cases listed above, a side-effect update to the list is not really needed to complete the operations on the incident variable list, hence it should be removed in this solution option as well.
b) There may be a possibility of a race condition in 2.0, according to Jay, so we will need to build some further robustness into these operations.
I propose that we change the add and remove operations to be dependent upon exceptions being generated for operations such as add, remove/destroy, such that indicators for the results on remove and add operations are returned to the user of the plugin.
This may be further than the scope of this issue, however, I am not sure. During initial testing for this functionality in the destroy() integration tests, I could not generate an exception based on reuse of an instance of IEnvironmentVariable retrieved from the IApplication instance, and using IEnvironmentVariable.destroy() twice. No exception is generated when you call the operation.
A lack of understanding of how the destroy() method is supposed to work may have been the reason that I was unable to generate the assumed to be available SSHOperationException.
However, are the service objects supposed to generate an exception when you attempt to remove a variable that does not exist?
was (Author: mwigglesworth-redhat):
Use Cases:
Add
1) add non-existing variable
2)add pre-existing variable
Remove
1) remove pre-existing variable
2) remove non-pre-existing variable
Solution analysis:
I. Simply remove the update operations from both the add and remove methods listed.
II. Remove update from remove, and leave it in add
III. Alter the current behaviours of the add and remove operations as follows:
a) The update should be removed from add and remove because nothing is actually done with the updated list, other than to make sure that the list is updated.
i)In the case that the add operation is successful, then your local variable list will simply reflect the remote list. The add method should then return boolean "true" based on the outcome of the operation.
ii)In the case that the add operation is not successful, then the add operation should capture the exception and return a boolean indication. The add method should then return boolean "false" based on the outcome of the operation.
iii)In the case for the remove operation, if the removal is successful, the list should already reflect the external list, and does not need to be updated. The remove method should then return boolean "true" based on the outcome of the operation.
iv) In the case for the remove operation that is not successful, a boolean of false should be rendered, and the list would still reflect the removed variable anyhow. The remove method should then return boolean "false" based on the outcome of the operation.
v) In all of the cases listed above, a side-effect update to the list is not really needed to complete the operations on the incident variable list, hence it should be removed in this solution option as well.
b) There may be a possibility of a race condition in 2.0, according to Jay, so we will need to build some further robustness into these operations.
I propose that we change the add and remove operations to be dependent upon exceptions being generated for operations such as add, remove/destroy, such that indicators for the results on remove and add operations are returned to the user of the plugin.
This may be further than the scope of this issue, however, I am not sure. During initial testing for this functionality in the destroy() integration tests, I could not generate an exception based on reuse of an instance of IEnvironmentVariable retrieved from the IApplication instance, and using IEnvironmentVariable.destroy() twice. No exception is generated when you call the operation.
A lack of understanding of how the destroy() method is supposed to work may have been the reason that I was unable to generate the assumed to be available SSHOperationException.
However, are the service objects supposed to generate an exception when you attempt to remove a variable that does not exist?
> openshift-java-client: dont refresh env variables on each addition/removal
> --------------------------------------------------------------------------
>
> Key: JBIDE-15766
> URL: https://issues.jboss.org/browse/JBIDE-15766
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: openshift
> Affects Versions: 4.1.1.Beta1, 4.2.0.Alpha1
> Reporter: Andre Dietisheim
> Assignee: Andre Dietisheim
> Fix For: 4.1.1.Beta1, 4.2.0.Alpha1
>
>
> When adding/removing environment variables, the openshift-java-client would always request the backend for the full list. This should not be required and avoided
> {code:title=ApplicationResource#addEnvironmentVariable}
> EnvironmentVariableResourceDTO environmentVariableResourceDTO =
> new AddEnvironmentVariableRequest().execute(name, value);
> IEnvironmentVariable environmentVariable = new EnvironmentVariableResource(environmentVariableResourceDTO, this);
> updateEnvironmentVariables();
> return environmentVariable;
> {code}
> {code:title=ApplicationResource#updateEnvironmentVariables}
> protected void updateEnvironmentVariables() throws OpenShiftException {
> if (environmentVariableByName == null) {
> environmentVariableByName = loadEnvironmentVariables();
> } else {
> environmentVariableByName.clear();
> environmentVariableByName.putAll(loadEnvironmentVariables());
> }
> }
> {code}
--
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
12 years, 8 months
[JBoss JIRA] (JBIDE-15766) openshift-java-client: dont refresh env variables on each addition/removal
by Martes Wigglesworth (JIRA)
[ https://issues.jboss.org/browse/JBIDE-15766?page=com.atlassian.jira.plugi... ]
Martes Wigglesworth edited comment on JBIDE-15766 at 10/23/13 11:12 PM:
------------------------------------------------------------------------
Use Cases:
Add
1) add non-existing variable
2)add pre-existing variable
Remove
1) remove pre-existing variable
2) remove non-pre-existing variable
Solution analysis:
I. Simply remove the update operations from both the add and remove methods listed.
II. Remove update from remove, and leave it in add
III. Alter the current behaviours of the add and remove operations as follows:
a) The update should be removed from add and remove because nothing is actually done with the updated list, other than to make sure that the list is updated.
i)In the case that the add operation is successful, then your local variable list will simply reflect the remote list. The add method should then return boolean "true" based on the outcome of the operation.
ii)In the case that the add operation is not successful, then the add operation should capture the exception and return a boolean indication. The add method should then return boolean "false" based on the outcome of the operation.
iii)In the case for the remove operation, if the removal is successful, the list should already reflect the external list, and does not need to be updated. The remove method should then return boolean "true" based on the outcome of the operation.
iv) In the case for the remove operation that is not successful, a boolean of false should be rendered, and the list would still reflect the removed variable anyhow. The remove method should then return boolean "false" based on the outcome of the operation.
v) In all of the cases listed above, a side-effect update to the list is not really needed to complete the operations on the incident variable list, hence it should be removed in this solution option as well.
b) There may be a possibility of a race condition in 2.0, according to Jay, so we will need to build some further robustness into these operations.
I propose that we change the add and remove operations to be dependent upon exceptions being generated for operations such as add, remove/destroy, such that indicators for the results on remove and add operations are returned to the user of the plugin.
This may be further than the scope of this issue, however, I am not sure. During initial testing for this functionality in the destroy() integration tests, I could not generate an exception based on reuse of an instance of IEnvironmentVariable retrieved from the IApplication instance, and using IEnvironmentVariable.destroy() twice. No exception is generated when you call the operation.
A lack of understanding of how the destroy() method is supposed to work may have been the reason that I was unable to generate the assumed to be available SSHOperationException.
However, are the service objects supposed to generate an exception when you attempt to remove a variable that does not exist?
was (Author: mwigglesworth-redhat):
Use Cases:
Add
1) add non-existing variable
2)add pre-existing variable
Remove
1) remove pre-existing variable
2) remove non-pre-existing variable
Solution analysis:
a) The update should be removed from add and remove because nothing is actually done with the updated list, other than to make sure that the list is updated.
i)In the case that the add operation is successful, then your local variable list will simply reflect the remote list, and return a boolean indicator.
ii)In the case that the add operation is not successful, then the add operation should capture the exception and return a boolean indication.
iii)In the case for the remove operation, if the removal is successful, the list should already reflect the external list, and does not need to be updated.
iv) In the case for the remove operation that is not successful, a boolean of false should be rendered, and the list would still reflect the removed variable anyhow.
v) In all of the cases listed above, a side-effect update to the list is not really needed to complete the operations on the incident variable list.
b) There may be a possibility of a race condition in 2.0, according to Jay, so we will need to build some further robustness into these operations. I propose that we change the add and remove operations to be dependent upon exceptions being generated for operations such as add, remove/destroy, such that indicators for the results on remove and add operations are returned to the user of the plugin. This may be further than the scope of this issue, however, I am not sure. During initial testing for this functionality in the destroy() integration tests, I could not generate an exception based on reuse of an instance of IEnvironmentVariable retrieved from the IApplication instance, and using IEnvironmentVariable.destroy() twice. No exception is generated when you call the operation. A lack of understanding of how the destroy() method is supposed to work may have been the reason that I was unable to generate the assumed to be available SSHOperationException. However, is the api or the service object, supposed to generate an exception when you attempt to remove a variable that does not exist?
> openshift-java-client: dont refresh env variables on each addition/removal
> --------------------------------------------------------------------------
>
> Key: JBIDE-15766
> URL: https://issues.jboss.org/browse/JBIDE-15766
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: openshift
> Affects Versions: 4.1.1.Beta1, 4.2.0.Alpha1
> Reporter: Andre Dietisheim
> Assignee: Andre Dietisheim
> Fix For: 4.1.1.Beta1, 4.2.0.Alpha1
>
>
> When adding/removing environment variables, the openshift-java-client would always request the backend for the full list. This should not be required and avoided
> {code:title=ApplicationResource#addEnvironmentVariable}
> EnvironmentVariableResourceDTO environmentVariableResourceDTO =
> new AddEnvironmentVariableRequest().execute(name, value);
> IEnvironmentVariable environmentVariable = new EnvironmentVariableResource(environmentVariableResourceDTO, this);
> updateEnvironmentVariables();
> return environmentVariable;
> {code}
> {code:title=ApplicationResource#updateEnvironmentVariables}
> protected void updateEnvironmentVariables() throws OpenShiftException {
> if (environmentVariableByName == null) {
> environmentVariableByName = loadEnvironmentVariables();
> } else {
> environmentVariableByName.clear();
> environmentVariableByName.putAll(loadEnvironmentVariables());
> }
> }
> {code}
--
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
12 years, 8 months