[JBoss JIRA] (JBIDE-21153) Use extension in OpenShiftCoreUIIntegation
by Andre Dietisheim (JIRA)
Andre Dietisheim created JBIDE-21153:
----------------------------------------
Summary: Use extension in OpenShiftCoreUIIntegation
Key: JBIDE-21153
URL: https://issues.jboss.org/browse/JBIDE-21153
Project: Tools (JBoss Tools)
Issue Type: Feature Request
Components: openshift
Affects Versions: 4.3.1.Beta1
Reporter: Andre Dietisheim
Assignee: Andre Dietisheim
Fix For: 4.3.1.Beta1
the Connection class resides in the openshift core plugin. It happens that connections need to pop up dialogs in order to ex. let the user confirm ssl signatures or provide a token/credentials. To allow class to do this we have the OpenShiftCoreUIntegration currently, which is initialized by the activator in org.jboss.tools.openshift.ui by injecting the dialogs into OpenShiftCoreUIIntegration. This works fine as long as some UI is started before the connection gets activated. When creating a server adapter this doesnt work any more. The openshift server adapter resides in org.jboss.tools.openshift.core only, there's no openshift UI involved. The connection is therefore not able to prompt the user for a new token etc.
We therefore have to change the current injection based approach (ui injects dialogs into core) by a extension point that the core is querying as soon as it requires some UI.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 5 months
[JBoss JIRA] (JBIDE-21153) Use extension in OpenShiftCoreUIIntegation
by Andre Dietisheim (JIRA)
[ https://issues.jboss.org/browse/JBIDE-21153?page=com.atlassian.jira.plugi... ]
Andre Dietisheim updated JBIDE-21153:
-------------------------------------
Labels: openshift_v3 (was: )
> Use extension in OpenShiftCoreUIIntegation
> ------------------------------------------
>
> Key: JBIDE-21153
> URL: https://issues.jboss.org/browse/JBIDE-21153
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: openshift
> Affects Versions: 4.3.1.Beta1
> Reporter: Andre Dietisheim
> Assignee: Andre Dietisheim
> Labels: openshift_v3
> Fix For: 4.3.1.Beta1
>
>
> the Connection class resides in the openshift core plugin. It happens that connections need to pop up dialogs in order to ex. let the user confirm ssl signatures or provide a token/credentials. To allow class to do this we have the OpenShiftCoreUIntegration currently, which is initialized by the activator in org.jboss.tools.openshift.ui by injecting the dialogs into OpenShiftCoreUIIntegration. This works fine as long as some UI is started before the connection gets activated. When creating a server adapter this doesnt work any more. The openshift server adapter resides in org.jboss.tools.openshift.core only, there's no openshift UI involved. The connection is therefore not able to prompt the user for a new token etc.
> We therefore have to change the current injection based approach (ui injects dialogs into core) by a extension point that the core is querying as soon as it requires some UI.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 5 months
[JBoss JIRA] (JBIDE-21152) Cannot deploy mvn module of an existing git-based application to OpenShift 3 server
by Marián Labuda (JIRA)
[ https://issues.jboss.org/browse/JBIDE-21152?page=com.atlassian.jira.plugi... ]
Marián Labuda updated JBIDE-21152:
----------------------------------
Description:
If a git-based project it maven module and it has some parent (like eap quickstarts available at https://github.com/jboss-developer/jboss-eap-quickstarts) it is not possible to deploy such a project. There is an error in New OpenShift Application wizrad telling that a project is not git project, although it is. There was similar issue with OpenShift 2 and with deploying projects which did not have .git folder in itself but it was in parent. See following screenshot:
!application_wizard.png!
was:
If a git-based project it maven module and it has some parent (like eap quickstarts available at https://github.com/jboss-developer/jboss-eap-quickstarts) it is not possible to deploy such a project. There is an error in New OpenShift Application wizrad telling that a project is not git project, although it is. See following screenshot:
!application_wizard.png!
> Cannot deploy mvn module of an existing git-based application to OpenShift 3 server
> -----------------------------------------------------------------------------------
>
> Key: JBIDE-21152
> URL: https://issues.jboss.org/browse/JBIDE-21152
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: openshift
> Affects Versions: 4.3.1.Beta1
> Reporter: Marián Labuda
> Priority: Critical
> Attachments: application_wizard.png
>
>
> If a git-based project it maven module and it has some parent (like eap quickstarts available at https://github.com/jboss-developer/jboss-eap-quickstarts) it is not possible to deploy such a project. There is an error in New OpenShift Application wizrad telling that a project is not git project, although it is. There was similar issue with OpenShift 2 and with deploying projects which did not have .git folder in itself but it was in parent. See following screenshot:
> !application_wizard.png!
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 5 months
[JBoss JIRA] (JBIDE-21152) Cannot deploy mvn module of an existing git-based application to OpenShift 3 server
by Marián Labuda (JIRA)
[ https://issues.jboss.org/browse/JBIDE-21152?page=com.atlassian.jira.plugi... ]
Marián Labuda updated JBIDE-21152:
----------------------------------
Description:
If a git-based project it maven module and it has some parent (like eap quickstarts available at https://github.com/jboss-developer/jboss-eap-quickstarts) it is not possible to deploy such a project. There is an error in New OpenShift Application wizard telling that a project is not git project, although it is. There was similar issue with OpenShift 2 and with deploying projects which did not have .git folder in itself but it was in parent. See following screenshot:
!application_wizard.png!
was:
If a git-based project it maven module and it has some parent (like eap quickstarts available at https://github.com/jboss-developer/jboss-eap-quickstarts) it is not possible to deploy such a project. There is an error in New OpenShift Application wizrad telling that a project is not git project, although it is. There was similar issue with OpenShift 2 and with deploying projects which did not have .git folder in itself but it was in parent. See following screenshot:
!application_wizard.png!
> Cannot deploy mvn module of an existing git-based application to OpenShift 3 server
> -----------------------------------------------------------------------------------
>
> Key: JBIDE-21152
> URL: https://issues.jboss.org/browse/JBIDE-21152
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: openshift
> Affects Versions: 4.3.1.Beta1
> Reporter: Marián Labuda
> Priority: Critical
> Attachments: application_wizard.png
>
>
> If a git-based project it maven module and it has some parent (like eap quickstarts available at https://github.com/jboss-developer/jboss-eap-quickstarts) it is not possible to deploy such a project. There is an error in New OpenShift Application wizard telling that a project is not git project, although it is. There was similar issue with OpenShift 2 and with deploying projects which did not have .git folder in itself but it was in parent. See following screenshot:
> !application_wizard.png!
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 5 months
[JBoss JIRA] (JBIDE-21151) Button file system in OpenShift Application wizard causes an error
by Marián Labuda (JIRA)
Marián Labuda created JBIDE-21151:
-------------------------------------
Summary: Button file system in OpenShift Application wizard causes an error
Key: JBIDE-21151
URL: https://issues.jboss.org/browse/JBIDE-21151
Project: Tools (JBoss Tools)
Issue Type: Bug
Components: openshift
Affects Versions: 4.3.1.Beta1
Reporter: Marián Labuda
Priority: Blocker
In New OpenShift Application wizard on the first wizard page where selection of a template is, there is a button "File system..." which is supposed to open a file browser dialog, but nothing happens after click on it and following error with stacktrace is present in error log:
{code}
Unhandled event loop exception
java.lang.NullPointerException
at org.eclipse.core.internal.variables.StringSubstitutionEngine.substitute(StringSubstitutionEngine.java:137)
at org.eclipse.core.internal.variables.StringSubstitutionEngine.performStringSubstitution(StringSubstitutionEngine.java:87)
at org.eclipse.core.internal.variables.StringVariableManager.performStringSubstitution(StringVariableManager.java:592)
at org.eclipse.core.internal.variables.StringVariableManager.performStringSubstitution(StringVariableManager.java:358)
at org.jboss.tools.openshift.internal.ui.wizard.newapp.TemplateListPage.substituteVariables(TemplateListPage.java:956)
at org.jboss.tools.openshift.internal.ui.wizard.newapp.TemplateListPage.isFile(TemplateListPage.java:545)
at org.jboss.tools.openshift.internal.ui.wizard.newapp.TemplateListPage.access$2(TemplateListPage.java:544)
at org.jboss.tools.openshift.internal.ui.wizard.newapp.TemplateListPage$14.createFileDialog(TemplateListPage.java:710)
at org.jboss.tools.openshift.internal.ui.wizard.newapp.TemplateListPage$14.widgetSelected(TemplateListPage.java:702)
at org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:248)
at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84)
at org.eclipse.swt.widgets.Display.sendEvent(Display.java:4481)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1329)
at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:3819)
at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3430)
at org.eclipse.jface.window.Window.runEventLoop(Window.java:827)
at org.eclipse.jface.window.Window.open(Window.java:803)
at org.jboss.tools.common.ui.WizardUtils.openWizardDialog(WizardUtils.java:279)
at org.jboss.tools.common.ui.WizardUtils.openWizardDialog(WizardUtils.java:270)
at org.jboss.tools.openshift.internal.ui.handler.NewApplicationHandler.execute(NewApplicationHandler.java:37)
at org.eclipse.ui.internal.handlers.HandlerProxy.execute(HandlerProxy.java:295)
at org.eclipse.ui.internal.handlers.E4HandlerProxy.execute(E4HandlerProxy.java:90)
at sun.reflect.GeneratedMethodAccessor75.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at org.eclipse.e4.core.internal.di.MethodRequestor.execute(MethodRequestor.java:56)
at org.eclipse.e4.core.internal.di.InjectorImpl.invokeUsingClass(InjectorImpl.java:252)
at org.eclipse.e4.core.internal.di.InjectorImpl.invoke(InjectorImpl.java:234)
at org.eclipse.e4.core.contexts.ContextInjectionFactory.invoke(ContextInjectionFactory.java:132)
at org.eclipse.e4.core.commands.internal.HandlerServiceHandler.execute(HandlerServiceHandler.java:152)
at org.eclipse.core.commands.Command.executeWithChecks(Command.java:493)
at org.eclipse.core.commands.ParameterizedCommand.executeWithChecks(ParameterizedCommand.java:486)
at org.eclipse.e4.core.commands.internal.HandlerServiceImpl.executeHandler(HandlerServiceImpl.java:210)
at org.eclipse.e4.ui.workbench.renderers.swt.HandledContributionItem.executeItem(HandledContributionItem.java:799)
at org.eclipse.e4.ui.workbench.renderers.swt.HandledContributionItem.handleWidgetSelection(HandledContributionItem.java:675)
at org.eclipse.e4.ui.workbench.renderers.swt.HandledContributionItem.access$7(HandledContributionItem.java:659)
at org.eclipse.e4.ui.workbench.renderers.swt.HandledContributionItem$4.handleEvent(HandledContributionItem.java:592)
at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84)
at org.eclipse.swt.widgets.Display.sendEvent(Display.java:4481)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1329)
at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:3819)
at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3430)
at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$4.run(PartRenderingEngine.java:1127)
at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:337)
at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(PartRenderingEngine.java:1018)
at org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(E4Workbench.java:156)
at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:654)
at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:337)
at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:598)
at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:150)
at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:139)
at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:134)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:104)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:380)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:235)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:669)
at org.eclipse.equinox.launcher.Main.basicRun(Main.java:608)
at org.eclipse.equinox.launcher.Main.run(Main.java:1515)
at org.eclipse.equinox.launcher.Main.main(Main.java:1488)
{code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 5 months
[JBoss JIRA] (JBIDE-21150) Provide a way to change one's mind about accepting an SSL certificate
by Jan Richter (JIRA)
Jan Richter created JBIDE-21150:
-----------------------------------
Summary: Provide a way to change one's mind about accepting an SSL certificate
Key: JBIDE-21150
URL: https://issues.jboss.org/browse/JBIDE-21150
Project: Tools (JBoss Tools)
Issue Type: Enhancement
Components: openshift
Affects Versions: 4.3.1.Beta1
Reporter: Jan Richter
The tooling will only give the user one chance to accept/deny the SSL certificate, which happens on start of the session. This is particularly annoying when for some reason the user denies the certificate (or just cancels the dialog) because the only way to reset it is to restart the IDE.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 5 months
[JBoss JIRA] (JBIDE-21141) OpenShift Application Wizard: Tags for application templates should be grey
by Marián Labuda (JIRA)
[ https://issues.jboss.org/browse/JBIDE-21141?page=com.atlassian.jira.plugi... ]
Marián Labuda commented on JBIDE-21141:
---------------------------------------
Yeah, it seems to be GTK3 issue because it is not happening on windows.
> OpenShift Application Wizard: Tags for application templates should be grey
> ---------------------------------------------------------------------------
>
> Key: JBIDE-21141
> URL: https://issues.jboss.org/browse/JBIDE-21141
> Project: Tools (JBoss Tools)
> Issue Type: Enhancement
> Components: openshift
> Affects Versions: 4.3.1.Beta1
> Reporter: Marián Labuda
> Priority: Minor
> Labels: application_wizard, openshift_v3
>
> In New OpenShift application on first wizard page is tree of server application templates. Application templates of internal OSE 3 instance are currently shown together with tags in the same way. It would be nice if tags - the key words in parenthesis e.g. "(java, eap, jboss, xpaas)" - would be shown as styled text (gray) as less significant information. We should show difference between template name and tags.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 5 months
[JBoss JIRA] (JBIDE-21149) Improve implementation of EGitUtils.getDefaultRemoteRepo()
by Andre Dietisheim (JIRA)
[ https://issues.jboss.org/browse/JBIDE-21149?page=com.atlassian.jira.plugi... ]
Andre Dietisheim updated JBIDE-21149:
-------------------------------------
Fix Version/s: 4.3.1.Beta1
4.4.0.Alpha1
> Improve implementation of EGitUtils.getDefaultRemoteRepo()
> ----------------------------------------------------------
>
> Key: JBIDE-21149
> URL: https://issues.jboss.org/browse/JBIDE-21149
> Project: Tools (JBoss Tools)
> Issue Type: Enhancement
> Components: openshift
> Affects Versions: 4.4.0.Alpha1
> Reporter: Viacheslav Kabanovich
> Assignee: Viacheslav Kabanovich
> Labels: code_quality
> Fix For: 4.3.1.Beta1, 4.4.0.Alpha1
>
>
> When a class provides for some collection property methods "get all", "get first", "has some" it is not a good pattern to 'reuse' "get all" to implement the other methods. For large collections that pattern ends up with bad performance. For small collections the performance is not critical, but it is a good idea to keep to right patterns to avoid an accidental applying a wrong one to a critical case.
> Method EGitUtils.getRemoteGitRepos(IProject) uses advanced API of Java 1.8 for handling collections, but EGitUtils.getDefaultRemoteRepo() just reuses it to get the first element of the list. Java 1.8 Stream operations allow preparing query that is processed on applying a consumer operation. So, if "get first" and "get all" may use the same stream query, we can privately prepare it to be reused in "get first" with Stream.findFirst() and in "get all" with Stream.collect(). [~adietish] please take a look at the attached pull request.
> Method getRemoteGitRepos(IProject) is now used just once in TemplateListPageValidator.validate() only to check that the list is not empty. So it could instead call getDefaultRemoteRepo() and check that it is not null. But while getDefaultRemoteRepo() is implemented with a call to getRemoteGitRepos(), it does not matter what method to call at that point. Thus, a wrong pattern in implementing API (EGitUtils) is followed by a wrong pattern in using it.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 5 months
[JBoss JIRA] (JBIDE-21149) Improve implementation of EGitUtils.getDefaultRemoteRepo()
by Viacheslav Kabanovich (JIRA)
[ https://issues.jboss.org/browse/JBIDE-21149?page=com.atlassian.jira.plugi... ]
Viacheslav Kabanovich updated JBIDE-21149:
------------------------------------------
Description:
When a class provides for some collection property methods "get all", "get first", "has some" it is not a good pattern to 'reuse' "get all" to implement the other methods. For large collections that pattern ends up with bad performance. For small collections the performance is not critical, but it is a good idea to keep to right patterns to avoid an accidental applying a wrong one to a critical case.
Method EGitUtils.getRemoteGitRepos(IProject) uses advanced API of Java 1.8 for handling collections, but EGitUtils.getDefaultRemoteRepo() just reuses it to get the first element of the list. Java 1.8 Stream operations allow preparing query that is processed on applying a consumer operation. So, if "get first" and "get all" may use the same stream query, we can privately prepare it to be reused in "get first" with Stream.findFirst() and in "get all" with Stream.collect(). [~adietish] please take a look at the attached pull request.
Method getRemoteGitRepos(IProject) is now used just once in TemplateListPageValidator.validate() only to check that the list is not empty. So it could instead call getDefaultRemoteRepo() and check that it is not null. But while getDefaultRemoteRepo() is implemented with a call to getRemoteGitRepos(), it does not matter what method to call at that point. Thus, a wrong pattern in implementing API (EGitUtils) is followed by a wrong pattern in using it.
was:
When a class provides for some collection property methods "get all", "get first", "has some" it is not a good pattern to 'reuse' "get all" to implement the other methods. For large collections that pattern ends up with bad performance. For small collections the performance is not critical, but it a good idea to keep to right patterns to avoid an accidental applying a wrong pattern to a critical case.
Method EGitUtils.getRemoteGitRepos(IProject) uses advanced API of Java 1.8 for handling collections, but EGitUtils.getDefaultRemoteRepo() just reuses it to get the first element of the list. Java 1.8 Stream operations allow preparing query that is processed on applying a consumer operation. So, if "get first" and "get all" may use the same stream query, we can privately prepare it to be reused in "get first" with Stream.findFirst() and in "get all" with Stream.collect(). [~adietish] please take a look at the attached pull request.
Method getRemoteGitRepos(IProject) is now used just once in TemplateListPageValidator.validate() only to check that the list is not empty. So it could instead call getDefaultRemoteRepo() and check that it is not null. But while getDefaultRemoteRepo() is implemented with a call to getRemoteGitRepos(), it does not matter what method to call at that point. Thus, a wrong pattern in implementing API (EGitUtils) is followed by a wrong pattern in using it.
> Improve implementation of EGitUtils.getDefaultRemoteRepo()
> ----------------------------------------------------------
>
> Key: JBIDE-21149
> URL: https://issues.jboss.org/browse/JBIDE-21149
> Project: Tools (JBoss Tools)
> Issue Type: Enhancement
> Components: openshift
> Affects Versions: 4.4.0.Alpha1
> Reporter: Viacheslav Kabanovich
> Assignee: Viacheslav Kabanovich
> Labels: code_quality
>
> When a class provides for some collection property methods "get all", "get first", "has some" it is not a good pattern to 'reuse' "get all" to implement the other methods. For large collections that pattern ends up with bad performance. For small collections the performance is not critical, but it is a good idea to keep to right patterns to avoid an accidental applying a wrong one to a critical case.
> Method EGitUtils.getRemoteGitRepos(IProject) uses advanced API of Java 1.8 for handling collections, but EGitUtils.getDefaultRemoteRepo() just reuses it to get the first element of the list. Java 1.8 Stream operations allow preparing query that is processed on applying a consumer operation. So, if "get first" and "get all" may use the same stream query, we can privately prepare it to be reused in "get first" with Stream.findFirst() and in "get all" with Stream.collect(). [~adietish] please take a look at the attached pull request.
> Method getRemoteGitRepos(IProject) is now used just once in TemplateListPageValidator.validate() only to check that the list is not empty. So it could instead call getDefaultRemoteRepo() and check that it is not null. But while getDefaultRemoteRepo() is implemented with a call to getRemoteGitRepos(), it does not matter what method to call at that point. Thus, a wrong pattern in implementing API (EGitUtils) is followed by a wrong pattern in using it.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 5 months