[JBoss JIRA] (JBTIS-331) Get the integration stack into Early Access in JBoss Central
by Max Rydahl Andersen (JIRA)
[ https://issues.jboss.org/browse/JBTIS-331?page=com.atlassian.jira.plugin.... ]
Max Rydahl Andersen edited comment on JBTIS-331 at 10/8/14 7:35 AM:
--------------------------------------------------------------------
no, ....why is this so hard ;)
we have the following sites for our plugins:
/nightly
/staging
/development
/stable (edited, was release by error before)
Each matching the state we are in various development phases.
in past we had integration-stack, central, etc. versions of these handed out as public separate sub-urls
The change in JBDS-3086 is that these are now composited so we only need to use the root of these sites (/development, /release) when published to users to consume it. Internally we still have individual sites for compositing/testing, but they aren't supposed to be exposed as stable urls to users.
Then the intent is that when we do milestones we make it available in the matching category.
i.e. right now we got JBoss Tools CR1 in /development and optimally we would get JBoss Tools IS Beta into /development too and thus made available in jboss central for install.
when JBoss Tools core goes Final, IS Beta can't just be listed as being installable thus IF we want it available we have /earlyaccess site to provide this and users will have to go and explicit enable EA to get it.
Since you can't just have Final central pointing to /development site since then you will be mixing JBoss Tools 4.2.1.x into the release unknowingly.
I can see it is probably a bad thing if when are in Core Alpha/Beta/CR1 that IS won't show up as Earlyaccess when it will be that in Final/GA of tools. Thus we could still use the EA marker, but still at GA time integration stack needs to physically be in /earlyaccess location not in /development.
was (Author: maxandersen):
no, ....why is this so hard ;)
we have the following sites for our plugins:
/nightly
/staging
/development
/release
Each matching the state we are in various development phases.
in past we had integration-stack, central, etc. versions of these handed out as public separate sub-urls
The change in JBDS-3086 is that these are now composited so we only need to use the root of these sites (/development, /release) when published to users to consume it. Internally we still have individual sites for compositing/testing, but they aren't supposed to be exposed as stable urls to users.
Then the intent is that when we do milestones we make it available in the matching category.
i.e. right now we got JBoss Tools CR1 in /development and optimally we would get JBoss Tools IS Beta into /development too and thus made available in jboss central for install.
when JBoss Tools core goes Final, IS Beta can't just be listed as being installable thus IF we want it available we have /earlyaccess site to provide this and users will have to go and explicit enable EA to get it.
Since you can't just have Final central pointing to /development site since then you will be mixing JBoss Tools 4.2.1.x into the release unknowingly.
I can see it is probably a bad thing if when are in Core Alpha/Beta/CR1 that IS won't show up as Earlyaccess when it will be that in Final/GA of tools. Thus we could still use the EA marker, but still at GA time integration stack needs to physically be in /earlyaccess location not in /development.
> Get the integration stack into Early Access in JBoss Central
> ------------------------------------------------------------
>
> Key: JBTIS-331
> URL: https://issues.jboss.org/browse/JBTIS-331
> Project: JBoss Tools Integration Stack
> Issue Type: Feature Request
> Components: distribution
> Affects Versions: 8.0.0.Alpha2
> Reporter: Paul Leacu
> Assignee: Paul Leacu
>
> Procedure for encorporating the IS into Early Access.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 7 months
[JBoss JIRA] (JBIDE-18334) ClassCastException: ColumnProxy cannot be cast to IValue
by Jiri Peterka (JIRA)
[ https://issues.jboss.org/browse/JBIDE-18334?page=com.atlassian.jira.plugi... ]
Jiri Peterka closed JBIDE-18334.
--------------------------------
Verified with JBDS 8.0.0.CR2, Fedora 20_64
> ClassCastException: ColumnProxy cannot be cast to IValue
> --------------------------------------------------------
>
> Key: JBIDE-18334
> URL: https://issues.jboss.org/browse/JBIDE-18334
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: hibernate
> Affects Versions: 4.2.0.CR1
> Environment: JBDS 8.0.0.CR1b, L64
> Reporter: Jiri Peterka
> Assignee: Koen Aers
> Priority: Critical
> Fix For: 4.2.0.CR2
>
> Attachments: ccexception-hb-mapping.png
>
>
> {code}
> java.lang.ClassCastException: org.jboss.tools.hibernate.proxy.ColumnProxy cannot be cast to org.jboss.tools.hibernate.spi.IValue
> at org.jboss.tools.hibernate.ui.diagram.editors.parts.ShapeEditPart.getSelectionColor(ShapeEditPart.java:332)
> at org.jboss.tools.hibernate.ui.diagram.editors.parts.ShapeEditPart.updateSelected(ShapeEditPart.java:109)
> at org.jboss.tools.hibernate.ui.diagram.editors.parts.ShapeEditPart.propertyChange(ShapeEditPart.java:91)
> at java.beans.PropertyChangeSupport.fire(PropertyChangeSupport.java:335)
> at java.beans.PropertyChangeSupport.firePropertyChange(PropertyChangeSupport.java:327)
> at java.beans.PropertyChangeSupport.firePropertyChange(PropertyChangeSupport.java:263)
> at org.jboss.tools.hibernate.ui.diagram.editors.model.BaseElement.firePropertyChange(BaseElement.java:57)
> at org.jboss.tools.hibernate.ui.diagram.editors.model.BaseElement.setSelected(BaseElement.java:216)
> at org.jboss.tools.hibernate.ui.diagram.editors.model.Connection.setSelected(Connection.java:175)
> at org.jboss.tools.hibernate.ui.diagram.editors.parts.ShapeEditPart$ShapesSelectionEditPolicy.showSelection(ShapeEditPart.java:361)
> at org.eclipse.gef.editpolicies.SelectionEditPolicy.showPrimarySelection(SelectionEditPolicy.java:157)
> at org.eclipse.gef.editpolicies.SelectionEditPolicy.setSelectedState(SelectionEditPolicy.java:137)
> at org.eclipse.gef.editpolicies.SelectionEditPolicy$1.selectedStateChanged(SelectionEditPolicy.java:57)
> at org.eclipse.gef.editparts.AbstractEditPart.fireSelectionChanged(AbstractEditPart.java:436)
> at org.eclipse.gef.editparts.AbstractEditPart.setSelected(AbstractEditPart.java:1067)
> at org.eclipse.gef.SelectionManager.appendSelection(SelectionManager.java:81)
> at org.eclipse.gef.ui.parts.AbstractEditPartViewer.appendSelection(AbstractEditPartViewer.java:190)
> at org.eclipse.gef.ui.parts.AbstractEditPartViewer.select(AbstractEditPartViewer.java:599)
> at org.eclipse.gef.tools.SelectEditPartTracker.performSelection(SelectEditPartTracker.java:221)
> at org.eclipse.gef.tools.SelectEditPartTracker.performConditionalSelection(SelectEditPartTracker.java:167)
> at org.eclipse.gef.tools.SelectEditPartTracker.handleButtonDown(SelectEditPartTracker.java:92)
> at org.eclipse.gef.tools.AbstractTool.mouseDown(AbstractTool.java:1091)
> at org.eclipse.gef.tools.SelectionTool.mouseDown(SelectionTool.java:514)
> at org.eclipse.gef.EditDomain.mouseDown(EditDomain.java:245)
> at org.eclipse.gef.ui.parts.DomainEventDispatcher.dispatchMousePressed(DomainEventDispatcher.java:348)
> at org.eclipse.draw2d.LightweightSystem$EventHandler.mouseDown(LightweightSystem.java:523)
> at org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:192)
> at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84)
> at org.eclipse.swt.widgets.Display.sendEvent(Display.java:4486)
> at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1388)
> at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:3831)
> at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3441)
> at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$9.run(PartRenderingEngine.java:1151)
> at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
> at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(PartRenderingEngine.java:1032)
> at org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(E4Workbench.java:148)
> at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:636)
> at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
> at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:579)
> at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:150)
> at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:135)
> 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:382)
> at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:236)
> 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:648)
> at org.eclipse.equinox.launcher.Main.basicRun(Main.java:603)
> at org.eclipse.equinox.launcher.Main.run(Main.java:1465)
> at org.eclipse.equinox.launcher.Main.main(Main.java:1438)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 7 months
[JBoss JIRA] (TOOLSDOC-521) Review JIRA queries in Release Notes
by Martin Malina (JIRA)
[ https://issues.jboss.org/browse/TOOLSDOC-521?page=com.atlassian.jira.plug... ]
Martin Malina commented on TOOLSDOC-521:
----------------------------------------
[~mmurray], sorry for the delay. As for the "Resolved" query. I can see the new "fixVersion not" in there - what's the purpose? Is that to avoid listing JIRAs that have been fixed in the maintenance (4.1.x) as well as in 4.2?
Otherwise, I still don't like the "affectedVersion" there - if I remove it, the list gets from 180 JIRAs to more than 1000.
If I search only for JIRAs which have affectedVersion empty, I get 128 JIRAs - these are JIRAs that could have been reported for any version at all, we don't know. But ok, the majority of JIRAs has this set. Still, the fact that a JIRA has "affects 4.2.0.Beta3" does not necessarily mean that 4.1 is not affected - I would estimate that more often than not, 4.1 will be affected as well.
But I'm not sure what the right query should be then. Personally I would like it better if we just removed the "affectedVersion" from it.
[~ldimaggio], [~maxandersen], what do you think about this? What kind of query should we have in the release notes?
The Known issues filter looks ok to me.
> Review JIRA queries in Release Notes
> ------------------------------------
>
> Key: TOOLSDOC-521
> URL: https://issues.jboss.org/browse/TOOLSDOC-521
> Project: Documentation for JBoss Tools and Developer Studio
> Issue Type: Task
> Components: Release Notes
> Affects Versions: 4.2.0.CR1
> Reporter: Martin Malina
> Assignee: Michelle Murray
> Fix For: 4.2.0.Final
>
>
> When reviewing RNs for JBDS 8.0.0.CR1, we came to the conclusion that the JIRA queries may need updating.
> For reference, here's is discussion between me and Michelle on the subject:
> {quote}
> 01:23 mmalina: mmurray: I have a question about RN - resolved issues: (project in (JBDS) AND affectedVersion < "8.0.0.CR1" AND fixVersion in ("8.0.0.CR1") OR project in (JBIDE) AND affectedVersion < "4.2.0.CR1" AND fixVersion in ("4.2.0.CR1")) AND type in (Bug) AND resolution in (Done)
> 01:24 mmalina: mmurray: why have the fixVersion there? any special reason?
> 01:24 mmalina: mmurray: because it's 130 issues vs. 200 without it
> 01:24 maxandersen: don't use the < > comparisons. they unforatunely dont work reliably ;/
> 01:26 mmalina: maxandersen: the problem here is there are many jiras without affectedVersion
> 01:26 mmalina: *the main problem
> 01:26 mmalina: + what you say
> 01:27 maxandersen: mmalina: ah yeah. historically affectedVersion is only rarely used.
> 01:27 maxandersen: mmalina: only when we got very scifci issues where its important.
> 01:30 mmalina: mmurray: my only guess why you have it there is that you wanted to avoid jiras found in CR1 and fixed in CR1 - the thinking being that these would be new in CR1 and not present previously, thus you shouldn't list them in "what's fixed since the previous release". but that reasoning doesn't really work - 90 % bugs found in CR1 were already there before previously ;) any other reason to have it there?
> {quote}
> Michelle wrote:
> {quote}
> The search query is a best effort.
> The affects version is as you said, to avoid picking up internally identified bugs from QE/team testing CR1respinA that were fixed in CR1respinB, say. The customer doesn't need to know or care about these.
> The fixed version is a bit more complicated. The problem is that this query goes into the doc and the search results effectively have to remain static for all time - the doc could be hosted for years to come. This CR1 RNs doc should only list the bugs fixed in the CR1 release. If I leave the fixversion out then when bugs identified in <8.0.0.CR1 get resolved for CR2 or GA or even 9.1.0 they will show up in this query and that screws up the doc. The CR1 RNs doc we get replaced with a GA version so it isn't so important for this one but it is for the GA copy and it's easier to keep basically the same query as I iterate the doc towards GA.
> Regards using < and >, they are working effectively from what I can see. To make the comparisons work it just needs the versions to be listed in chronological order on the JBIDE and JBDS jira project pages.
> {quote}
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 7 months
[JBoss JIRA] (JBIDE-18538) Cheatsheet is not opened when project is imported as existing maven project
by Max Rydahl Andersen (JIRA)
[ https://issues.jboss.org/browse/JBIDE-18538?page=com.atlassian.jira.plugi... ]
Max Rydahl Andersen updated JBIDE-18538:
----------------------------------------
Priority: Critical (was: Major)
> Cheatsheet is not opened when project is imported as existing maven project
> ---------------------------------------------------------------------------
>
> Key: JBIDE-18538
> URL: https://issues.jboss.org/browse/JBIDE-18538
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: project-examples
> Affects Versions: 4.2.0.CR2
> Environment: Fedora 20, openjdk 1.8.0_11 64b
> Reporter: Radim Hopp
> Assignee: Snjezana Peco
> Priority: Critical
> Fix For: 4.2.0.CR2
>
>
> [~sgilda] wrote in JBDS-3152
> {quote}I installed jboss-devstudio-8.0.0.CR1-v20140915-0805-B246-installer-standalone.jar, started JDBS in a new workspace, and the cheatsheet does not open when I import kitchensink or helloworld (https://github.com/jboss-developer/jboss-eap-quickstarts). I'm using Fedora 20 and jdk1.7.0_51.{quote}
> I am experiencing the same problem on my Fedora 20 with jdk 1.8.0_11 64b.
> Import of maven project is smooth, but no cheatsheet is opened after that.
> Error log is silent.
> I double checked preferences (Preferences->JBoss Tools->Project Examples) and I have "Show Quick Fix dialog" checked and "Show included cheat shteet(s) when importing a new project" is set to Prompt.
> [~rawagner] Tried it as well (Ubuntu) and this is working for him.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 7 months
[JBoss JIRA] (JBIDE-18538) Cheatsheet is not opened when project is imported as existing maven project
by Max Rydahl Andersen (JIRA)
[ https://issues.jboss.org/browse/JBIDE-18538?page=com.atlassian.jira.plugi... ]
Max Rydahl Andersen updated JBIDE-18538:
----------------------------------------
Assignee: Snjezana Peco
> Cheatsheet is not opened when project is imported as existing maven project
> ---------------------------------------------------------------------------
>
> Key: JBIDE-18538
> URL: https://issues.jboss.org/browse/JBIDE-18538
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: project-examples
> Affects Versions: 4.2.0.CR2
> Environment: Fedora 20, openjdk 1.8.0_11 64b
> Reporter: Radim Hopp
> Assignee: Snjezana Peco
>
> [~sgilda] wrote in JBDS-3152
> {quote}I installed jboss-devstudio-8.0.0.CR1-v20140915-0805-B246-installer-standalone.jar, started JDBS in a new workspace, and the cheatsheet does not open when I import kitchensink or helloworld (https://github.com/jboss-developer/jboss-eap-quickstarts). I'm using Fedora 20 and jdk1.7.0_51.{quote}
> I am experiencing the same problem on my Fedora 20 with jdk 1.8.0_11 64b.
> Import of maven project is smooth, but no cheatsheet is opened after that.
> Error log is silent.
> I double checked preferences (Preferences->JBoss Tools->Project Examples) and I have "Show Quick Fix dialog" checked and "Show included cheat shteet(s) when importing a new project" is set to Prompt.
> [~rawagner] Tried it as well (Ubuntu) and this is working for him.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 7 months
[JBoss JIRA] (JBIDE-18538) Cheatsheet is not opened when project is imported as existing maven project
by Max Rydahl Andersen (JIRA)
[ https://issues.jboss.org/browse/JBIDE-18538?page=com.atlassian.jira.plugi... ]
Max Rydahl Andersen updated JBIDE-18538:
----------------------------------------
Fix Version/s: 4.2.0.CR2
> Cheatsheet is not opened when project is imported as existing maven project
> ---------------------------------------------------------------------------
>
> Key: JBIDE-18538
> URL: https://issues.jboss.org/browse/JBIDE-18538
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: project-examples
> Affects Versions: 4.2.0.CR2
> Environment: Fedora 20, openjdk 1.8.0_11 64b
> Reporter: Radim Hopp
> Assignee: Snjezana Peco
> Fix For: 4.2.0.CR2
>
>
> [~sgilda] wrote in JBDS-3152
> {quote}I installed jboss-devstudio-8.0.0.CR1-v20140915-0805-B246-installer-standalone.jar, started JDBS in a new workspace, and the cheatsheet does not open when I import kitchensink or helloworld (https://github.com/jboss-developer/jboss-eap-quickstarts). I'm using Fedora 20 and jdk1.7.0_51.{quote}
> I am experiencing the same problem on my Fedora 20 with jdk 1.8.0_11 64b.
> Import of maven project is smooth, but no cheatsheet is opened after that.
> Error log is silent.
> I double checked preferences (Preferences->JBoss Tools->Project Examples) and I have "Show Quick Fix dialog" checked and "Show included cheat shteet(s) when importing a new project" is set to Prompt.
> [~rawagner] Tried it as well (Ubuntu) and this is working for him.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 7 months
[JBoss JIRA] (JBDS-3152) Cheatsheet crashes silently when they need to open files
by Sande Gilda (JIRA)
[ https://issues.jboss.org/browse/JBDS-3152?page=com.atlassian.jira.plugin.... ]
Sande Gilda commented on JBDS-3152:
-----------------------------------
Thanks [~rawagner]. That helps!
> Cheatsheet crashes silently when they need to open files
> --------------------------------------------------------
>
> Key: JBDS-3152
> URL: https://issues.jboss.org/browse/JBDS-3152
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Bug
> Components: central
> Environment: JBDS 8.0.0.CR1b, OSX 10.9.4
> Reporter: Fred Bricon
> Assignee: Snjezana Peco
> Priority: Blocker
> Fix For: 8.0.0.CR2
>
>
> After creating a AngularJS Forge project, the cheatsheet opens, then, after clicking a couple times on the continue buttons, persistence.xml opens but the cheatsheet closes silently. The log shows :
> {quote}
> org.eclipse.swt.SWTException: Widget is disposed
> at org.eclipse.swt.SWT.error(SWT.java:4441)
> at org.eclipse.swt.SWT.error(SWT.java:4356)
> at org.eclipse.swt.SWT.error(SWT.java:4327)
> at org.eclipse.swt.widgets.Widget.error(Widget.java:783)
> at org.eclipse.swt.widgets.Widget.checkWidget(Widget.java:573)
> at org.eclipse.swt.widgets.Control.setCursor(Control.java:3659)
> at org.eclipse.ui.internal.cheatsheets.views.CheatSheetViewer.runSubItemPerformExecutable(CheatSheetViewer.java:1096)
> at org.eclipse.ui.internal.cheatsheets.views.CoreItem$4.linkActivated(CoreItem.java:198)
> at org.eclipse.ui.forms.widgets.AbstractHyperlink.handleActivate(AbstractHyperlink.java:233)
> at org.eclipse.ui.forms.widgets.ImageHyperlink.handleActivate(ImageHyperlink.java:199)
> at org.eclipse.ui.forms.widgets.AbstractHyperlink.handleMouseUp(AbstractHyperlink.java:327)
> at org.eclipse.ui.forms.widgets.AbstractHyperlink.access$2(AbstractHyperlink.java:311)
> at org.eclipse.ui.forms.widgets.AbstractHyperlink$4.handleEvent(AbstractHyperlink.java:125)
> at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84)
> at org.eclipse.swt.widgets.Display.sendEvent(Display.java:4188)
> at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1467)
> at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1490)
> at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1475)
> at org.eclipse.swt.widgets.Widget.notifyListeners(Widget.java:1279)
> at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:4031)
> at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3658)
> at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$9.run(PartRenderingEngine.java:1151)
> at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
> at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(PartRenderingEngine.java:1032)
> at org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(E4Workbench.java:148)
> at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:636)
> at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
> at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:579)
> at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:150)
> at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:135)
> 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:382)
> at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:236)
> 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:648)
> at org.eclipse.equinox.launcher.Main.basicRun(Main.java:603)
> at org.eclipse.equinox.launcher.Main.run(Main.java:1465)
> {quote}
> It used to work at some point, last week.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 7 months
[JBoss JIRA] (JBDS-3152) Cheatsheet crashes silently when they need to open files
by Sande Gilda (JIRA)
[ https://issues.jboss.org/browse/JBDS-3152?page=com.atlassian.jira.plugin.... ]
Sande Gilda commented on JBDS-3152:
-----------------------------------
I realize it's a hidden file, but that makes it very hard to open using the Help --> Cheat sheets... menu. :-)
> Cheatsheet crashes silently when they need to open files
> --------------------------------------------------------
>
> Key: JBDS-3152
> URL: https://issues.jboss.org/browse/JBDS-3152
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Bug
> Components: central
> Environment: JBDS 8.0.0.CR1b, OSX 10.9.4
> Reporter: Fred Bricon
> Assignee: Snjezana Peco
> Priority: Blocker
> Fix For: 8.0.0.CR2
>
>
> After creating a AngularJS Forge project, the cheatsheet opens, then, after clicking a couple times on the continue buttons, persistence.xml opens but the cheatsheet closes silently. The log shows :
> {quote}
> org.eclipse.swt.SWTException: Widget is disposed
> at org.eclipse.swt.SWT.error(SWT.java:4441)
> at org.eclipse.swt.SWT.error(SWT.java:4356)
> at org.eclipse.swt.SWT.error(SWT.java:4327)
> at org.eclipse.swt.widgets.Widget.error(Widget.java:783)
> at org.eclipse.swt.widgets.Widget.checkWidget(Widget.java:573)
> at org.eclipse.swt.widgets.Control.setCursor(Control.java:3659)
> at org.eclipse.ui.internal.cheatsheets.views.CheatSheetViewer.runSubItemPerformExecutable(CheatSheetViewer.java:1096)
> at org.eclipse.ui.internal.cheatsheets.views.CoreItem$4.linkActivated(CoreItem.java:198)
> at org.eclipse.ui.forms.widgets.AbstractHyperlink.handleActivate(AbstractHyperlink.java:233)
> at org.eclipse.ui.forms.widgets.ImageHyperlink.handleActivate(ImageHyperlink.java:199)
> at org.eclipse.ui.forms.widgets.AbstractHyperlink.handleMouseUp(AbstractHyperlink.java:327)
> at org.eclipse.ui.forms.widgets.AbstractHyperlink.access$2(AbstractHyperlink.java:311)
> at org.eclipse.ui.forms.widgets.AbstractHyperlink$4.handleEvent(AbstractHyperlink.java:125)
> at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84)
> at org.eclipse.swt.widgets.Display.sendEvent(Display.java:4188)
> at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1467)
> at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1490)
> at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1475)
> at org.eclipse.swt.widgets.Widget.notifyListeners(Widget.java:1279)
> at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:4031)
> at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3658)
> at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$9.run(PartRenderingEngine.java:1151)
> at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
> at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(PartRenderingEngine.java:1032)
> at org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(E4Workbench.java:148)
> at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:636)
> at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
> at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:579)
> at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:150)
> at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:135)
> 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:382)
> at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:236)
> 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:648)
> at org.eclipse.equinox.launcher.Main.basicRun(Main.java:603)
> at org.eclipse.equinox.launcher.Main.run(Main.java:1465)
> {quote}
> It used to work at some point, last week.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 7 months