[JBoss JIRA] (JBIDE-16032) java.lang.ArrayIndexOutOfBoundsException in Forge Runtime preferences
by Pavol Srna (JIRA)
[ https://issues.jboss.org/browse/JBIDE-16032?page=com.atlassian.jira.plugi... ]
Pavol Srna updated JBIDE-16032:
-------------------------------
Labels: respin-a (was: respin-a respin-b)
> java.lang.ArrayIndexOutOfBoundsException in Forge Runtime preferences
> ---------------------------------------------------------------------
>
> Key: JBIDE-16032
> URL: https://issues.jboss.org/browse/JBIDE-16032
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: forge
> Environment: Linux
> Reporter: Pavol Srna
> Assignee: Koen Aers
> Labels: respin-a
> Fix For: 4.1.1.Final
>
> Attachments: forge-preferences.png
>
>
> Stacktrace:
> {code}
> java.lang.ArrayIndexOutOfBoundsException: 0
> at org.jboss.tools.forge.ui.preferences.ForgeInstallationsPreferencePage$6.run(ForgeInstallationsPreferencePage.java:293)
> at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:70)
> at org.jboss.tools.forge.ui.preferences.ForgeInstallationsPreferencePage.performOk(ForgeInstallationsPreferencePage.java:290)
> at org.eclipse.jface.preference.PreferenceDialog$13.run(PreferenceDialog.java:965)
> at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
> at org.eclipse.ui.internal.JFaceUtil$1.run(JFaceUtil.java:49)
> at org.eclipse.jface.util.SafeRunnable.run(SafeRunnable.java:175)
> at org.eclipse.jface.preference.PreferenceDialog.okPressed(PreferenceDialog.java:945)
> at org.eclipse.ui.internal.dialogs.FilteredPreferenceDialog.okPressed(FilteredPreferenceDialog.java:448)
> at org.eclipse.ui.internal.dialogs.WorkbenchPreferenceDialog.okPressed(WorkbenchPreferenceDialog.java:171)
> at org.eclipse.jface.preference.PreferenceDialog.buttonPressed(PreferenceDialog.java:233)
> at org.eclipse.jface.dialogs.Dialog$2.widgetSelected(Dialog.java:628)
> 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.Widget.sendEvent(Widget.java:1392)
> at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:3742)
> at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3363)
> at org.eclipse.jface.window.Window.runEventLoop(Window.java:826)
> at org.eclipse.jface.window.Window.open(Window.java:802)
> at org.eclipse.ui.internal.dialogs.WorkbenchPreferenceDialog.open(WorkbenchPreferenceDialog.java:215)
> at org.eclipse.ui.internal.OpenPreferencesAction.run(OpenPreferencesAction.java:65)
> at org.eclipse.jface.action.Action.runWithEvent(Action.java:499)
> at org.eclipse.jface.action.ActionContributionItem.handleWidgetSelection(ActionContributionItem.java:584)
> at org.eclipse.jface.action.ActionContributionItem.access$2(ActionContributionItem.java:501)
> at org.eclipse.jface.action.ActionContributionItem$5.handleEvent(ActionContributionItem.java:411)
> at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84)
> at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1392)
> at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:3742)
> at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3363)
> at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$9.run(PartRenderingEngine.java:1113)
> at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
> at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(PartRenderingEngine.java:997)
> at org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(E4Workbench.java:138)
> at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:610)
> at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
> at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:567)
> at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:150)
> at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:124)
> at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196)
> at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110)
> at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79)
> at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:354)
> at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:181)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:636)
> at org.eclipse.equinox.launcher.Main.basicRun(Main.java:591)
> at org.eclipse.equinox.launcher.Main.run(Main.java:1450)
> at org.eclipse.equinox.launcher.Main.main(Main.java:1426)
> {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, 4 months
[JBoss JIRA] (JBIDE-16134) CordovaSim should start the livereload server
by Burr Sutter (JIRA)
[ https://issues.jboss.org/browse/JBIDE-16134?page=com.atlassian.jira.plugi... ]
Burr Sutter commented on JBIDE-16134:
-------------------------------------
One thing we should consider is...while Livereload is a "browser feature", available in all browsers (that installed the plugin), it is not obvious how a BrowserSim/CordovaSim end-user should enable it. It is common to have the "Enable LiveReload" menu-item checked on but not have the server configured nor started therefore "it just doesn't work" from the end-user's perspective.
One option that would make sense to me, if the end-user checks "Enable LiveReload" on and no server is configured and/or started (including an independent server) then we prompt the user with "Hey, we could not find a LiveReload Service at port 35729, would you like configure one inside of JBDS/Eclipse?"
> CordovaSim should start the livereload server
> ---------------------------------------------
>
> Key: JBIDE-16134
> URL: https://issues.jboss.org/browse/JBIDE-16134
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: browsersim
> Affects Versions: 4.1.1.CR1
> Reporter: Gorkem Ercan
> Assignee: Konstantin Marmalyukov
>
> CordovaSim should configure and start the livereload server when the livereload is enabled.
> If starting the server from CordovaSim menu is a big problem, alternately, the server can always be configured and started before a CordovaSim launch.
--
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, 4 months
[JBoss JIRA] (JBIDE-15388) Compute whether to publish or not based on output signature rather than commits
by Max Rydahl Andersen (JIRA)
[ https://issues.jboss.org/browse/JBIDE-15388?page=com.atlassian.jira.plugi... ]
Max Rydahl Andersen commented on JBIDE-15388:
---------------------------------------------
I don't understand why this changes with introduction of nexus ? you would still like to avoid publishing unnecessary updates to nexus...
> Compute whether to publish or not based on output signature rather than commits
> -------------------------------------------------------------------------------
>
> Key: JBIDE-15388
> URL: https://issues.jboss.org/browse/JBIDE-15388
> Project: Tools (JBoss Tools)
> Issue Type: Enhancement
> Components: build
> Reporter: Mickael Istria
> Assignee: Mickael Istria
> Fix For: LATER
>
>
> [Assuming we already have reproducible qualifiers...]
> Currently, the CI jobs publish the output of a build if a change was detected in the Git repo since last publication.
> However there are some case not correctly supported:
> * Job configuration changed and caused changes in build output. In that case, we would like build output to be re-published, but it won't happen
> * Job source changed but not build output (eg a change in a pom.xml or any non-included file), then we don't need to republish output whereas current mechanism would republish it.
> instead, it would make sense to compare what's already published and what is to publish in order to decide or not whether this has to be published. Looking at signatures of update site zip would probably be enough.
--
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, 4 months
[JBoss JIRA] (JBIDE-16100) OpenShift time out preference should show default 240 seconds and not 0
by Max Rydahl Andersen (JIRA)
[ https://issues.jboss.org/browse/JBIDE-16100?page=com.atlassian.jira.plugi... ]
Max Rydahl Andersen resolved JBIDE-16100.
-----------------------------------------
Fix Version/s: 4.1.1.CR1
Resolution: Rejected
marking this as invalid now that N&N have been updated to be closer to the truth on how it actually works. can still make the UI clearer and explain how it works there, but that would be separate issue.
> OpenShift time out preference should show default 240 seconds and not 0
> -----------------------------------------------------------------------
>
> Key: JBIDE-16100
> URL: https://issues.jboss.org/browse/JBIDE-16100
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: openshift
> Affects Versions: 4.1.1.CR1
> Environment: Version: 7.1.0.CR1
> Build id: CR1-v20131124-0717-B560
> Build date: 20131124-0717
> Reporter: Michelle Murray
> Assignee: Max Rydahl Andersen
> Fix For: 4.1.1.CR1
>
> Attachments: OpenShift_deftimeout.png
>
>
> Click Window > Preferences > JBoss Tools > OpenShift.
> Remote requests time out field states '0'.
> !OpenShift_deftimeout.png!
> If the default time out is 240 seconds (as stated in N&N) and I haven't changed the default time out, then this should read 240 - right?
--
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, 4 months
[JBoss JIRA] (JBIDE-16134) CordovaSim should start the livereload server
by Max Rydahl Andersen (JIRA)
[ https://issues.jboss.org/browse/JBIDE-16134?page=com.atlassian.jira.plugi... ]
Max Rydahl Andersen commented on JBIDE-16134:
---------------------------------------------
[~gercan] any browser that supports livereload shows enable livereload in their UI so that is not really an argument for adding it.
Why not just add a hook so livereload can show up when cordovasim launches or even when users are editing html and suggest to start ?
*Zero* dependencies needed from cordovasim (or browsersim, or even internet explorer, chrome or any otherbrowser supporting livereload ?)
Thats what we discussed on the quick call last week.
> CordovaSim should start the livereload server
> ---------------------------------------------
>
> Key: JBIDE-16134
> URL: https://issues.jboss.org/browse/JBIDE-16134
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: browsersim
> Affects Versions: 4.1.1.CR1
> Reporter: Gorkem Ercan
> Assignee: Konstantin Marmalyukov
>
> CordovaSim should configure and start the livereload server when the livereload is enabled.
> If starting the server from CordovaSim menu is a big problem, alternately, the server can always be configured and started before a CordovaSim launch.
--
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, 4 months
[JBoss JIRA] (JBIDE-15830) openshift-java-client: incompatibility with OpenShift Enterprise and Origin when using the remote-user authentication plugin
by Andre Dietisheim (JIRA)
[ https://issues.jboss.org/browse/JBIDE-15830?page=com.atlassian.jira.plugi... ]
Andre Dietisheim closed JBIDE-15830.
------------------------------------
closing, nothing for QE to verify
> openshift-java-client: incompatibility with OpenShift Enterprise and Origin when using the remote-user authentication plugin
> ----------------------------------------------------------------------------------------------------------------------------
>
> Key: JBIDE-15830
> URL: https://issues.jboss.org/browse/JBIDE-15830
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: openshift
> Affects Versions: 4.1.1.Beta1
> Reporter: Brenton Leanhardt
> Assignee: Andre Dietisheim
> Labels: openshift-java-client
> Fix For: 4.1.1.CR1, 4.2.0.Alpha1
>
>
> OpenShift Enterprise and Origin both ship an authentication plugin that allows parts of authentication to be handled by Apache and other parts to be delegated to the openshift-origin-controller codebase. I've found that all versions of openshift-java-client after 2.3.0.Final change a (poorly documented) requirement for the OpenShift remote-user plugin.
> In order for a request to bypass the Apache authentication and passthrough to the OpenShift Broker the user-agent header is inspected. If the user-agent is 'OpenShift' then the Broker will require an encrypted authentication token. Today this is used by the jenkins cartridge but I believe it's also still used for scaling.
> You can see this for details:
> https://github.com/openshift/origin-server/blob/master/documentation/arch...
> In 2.3.0.Final of the openshift-java-client the user-agent was 'OpenShift' however all versions after this set the user-agent to the java version (eg, User-Agent: Java/1.7.0_45).
--
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, 4 months