[JBoss JIRA] (JBIDE-19949) Application wizard: Should automatically import once the resources are created
by Andre Dietisheim (JIRA)
[ https://issues.jboss.org/browse/JBIDE-19949?page=com.atlassian.jira.plugi... ]
Andre Dietisheim updated JBIDE-19949:
-------------------------------------
Fix Version/s: 4.3.0.CR1
(was: 4.3.0.Beta2)
> Application wizard: Should automatically import once the resources are created
> ------------------------------------------------------------------------------
>
> Key: JBIDE-19949
> URL: https://issues.jboss.org/browse/JBIDE-19949
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: openshift
> Affects Versions: 4.3.0.Beta2
> Reporter: Jeff Cantrill
> Assignee: Andre Dietisheim
> Labels: application_wizard, import_wizard, openshift_v3
> Fix For: 4.3.0.CR1
>
>
> Run the new app from template wizard and import the app as an eclipse project when its complete
> # EXEC: create new application for a v3 connection using some template
> Result:
> There's no Eclipse project imported once the wizard created the resources. I have to manually import the project.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 11 months
[JBoss JIRA] (JBIDE-20125) v3 Import-, application wizard: use easy import, not our custom facility
by Andre Dietisheim (JIRA)
[ https://issues.jboss.org/browse/JBIDE-20125?page=com.atlassian.jira.plugi... ]
Andre Dietisheim commented on JBIDE-20125:
------------------------------------------
we went out of time for this in 4.3.0.Beta2, postponing
> v3 Import-, application wizard: use easy import, not our custom facility
> ------------------------------------------------------------------------
>
> Key: JBIDE-20125
> URL: https://issues.jboss.org/browse/JBIDE-20125
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: openshift
> Affects Versions: 4.3.0.Beta1
> Reporter: Andre Dietisheim
> Labels: openshift_v3
> Fix For: 4.3.0.CR1
>
>
> The current impl of the import wizard in v2 and v3 is using a custom import logic where it launches m2e for repositories that have a pom.xml and "General project" for all the others. In JBDS-3285 [~mickael_istria] contributed a new Easy import facility for Eclipse that we should use instead of our own minimalistic, custom made approach
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 11 months
[JBoss JIRA] (JBIDE-20125) v3 Import-, application wizard: use easy import, not our custom facility
by Andre Dietisheim (JIRA)
[ https://issues.jboss.org/browse/JBIDE-20125?page=com.atlassian.jira.plugi... ]
Andre Dietisheim updated JBIDE-20125:
-------------------------------------
Fix Version/s: 4.3.0.CR1
(was: 4.3.0.Beta2)
> v3 Import-, application wizard: use easy import, not our custom facility
> ------------------------------------------------------------------------
>
> Key: JBIDE-20125
> URL: https://issues.jboss.org/browse/JBIDE-20125
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: openshift
> Affects Versions: 4.3.0.Beta1
> Reporter: Andre Dietisheim
> Labels: openshift_v3
> Fix For: 4.3.0.CR1
>
>
> The current impl of the import wizard in v2 and v3 is using a custom import logic where it launches m2e for repositories that have a pom.xml and "General project" for all the others. In JBDS-3285 [~mickael_istria] contributed a new Easy import facility for Eclipse that we should use instead of our own minimalistic, custom made approach
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 11 months
[JBoss JIRA] (JBIDE-20217) JDT Debug can not connect/list VM started with suspend=y
by Rob Stryker (JIRA)
[ https://issues.jboss.org/browse/JBIDE-20217?page=com.atlassian.jira.plugi... ]
Rob Stryker commented on JBIDE-20217:
-------------------------------------
I dug in more, and honestly, I do not believe this is a bug.
A java process launched with suspend=y is frozen before executing, awaiting a debugger to connect. At this point, our jdt.debug plugin cannot poll the vm or ask it for details, since it has not yet truly launched. Once the user connects a remote debugger, though, the process shows up immediately in the JMX view, the process begins executing, and everything functions as expected.
Are there any other symptoms here that need to be addresse? It does not appear to be blowing away the stack or having any negative effect anywhere in the code. I can look into checking that it doesn't log too often and isn't filling up the log, but other than that, I don't think this is a bug at all, and it works as I would find reasonable.
> JDT Debug can not connect/list VM started with suspend=y
> --------------------------------------------------------
>
> Key: JBIDE-20217
> URL: https://issues.jboss.org/browse/JBIDE-20217
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: common/jst/core
> Affects Versions: 4.3.0.Beta1
> Reporter: Aslak Knutsen
> Assignee: Rob Stryker
> Priority: Critical
> Fix For: 4.3.0.CR1
>
>
> Having a VM started with suspend=y cause the following error to be logged from https://github.com/jbosstools/jbosstools-base/blob/master/common/plugins/... due to Exception thrown in ToolsCore.getJvmArgs
> Seemingly JVMStat can not connect to a suspended VM.
> {code}
> eclipse.buildId=4.5.0.I20150603-2000
> java.version=1.8.0_45
> java.vendor=Oracle Corporation
> BootLoader constants: OS=linux, ARCH=x86_64, WS=gtk, NL=en_US
> Command-line arguments: -os linux -ws gtk -arch x86_64
> org.jboss.tools.common.jdt.debug
> Error
> Wed Jul 08 17:16:00 CEST 2015
> {code}
> {code}
> java.lang.reflect.InvocationTargetException
> 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.jboss.tools.common.jdt.debug.tools.internal.Tools.getJvmArgs(Tools.java:780)
> at org.jboss.tools.common.jdt.debug.tools.ToolsCore.getJvmArgs(ToolsCore.java:98)
> at org.jboss.tools.common.jdt.debug.RemoteDebugActivator.getVmModelsUsingTools(RemoteDebugActivator.java:166)
> at org.jboss.tools.common.jdt.debug.RemoteDebugActivator.getVmModel(RemoteDebugActivator.java:145)
> at org.jboss.tools.common.jdt.debug.RemoteDebugActivator.getVmModels(RemoteDebugActivator.java:132)
> at org.jboss.tools.common.jdt.debug.RemoteDebugActivator.getDebugModels(RemoteDebugActivator.java:193)
> at org.jboss.tools.common.jdt.debug.RemoteDebugActivator.getDebugModels(RemoteDebugActivator.java:227)
> at org.jboss.tools.common.jdt.debug.ui.RemoteDebugUIActivator.discoverRemoteApplication(RemoteDebugUIActivator.java:137)
> at org.jboss.tools.common.jdt.debug.ui.RemoteDebugUIActivator$1.run(RemoteDebugUIActivator.java:93)
> at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
> Caused by: sun.jvmstat.monitor.MonitorException: Could not synchronize with target
> at sun.jvmstat.perfdata.monitor.v2_0.PerfDataBuffer.synchWithTarget(PerfDataBuffer.java:277)
> at sun.jvmstat.perfdata.monitor.v2_0.PerfDataBuffer.buildMonitorMap(PerfDataBuffer.java:131)
> at sun.jvmstat.perfdata.monitor.PerfDataBufferImpl.findByName(PerfDataBufferImpl.java:241)
> at sun.jvmstat.perfdata.monitor.AbstractPerfDataBuffer.findByName(AbstractPerfDataBuffer.java:100)
> at sun.jvmstat.perfdata.monitor.AbstractMonitoredVm.findByName(AbstractMonitoredVm.java:85)
> at sun.jvmstat.monitor.MonitoredVmUtil.jvmArgs(MonitoredVmUtil.java:145)
> ... 14 more
> Root exception:
> sun.jvmstat.monitor.MonitorException: Could not synchronize with target
> at sun.jvmstat.perfdata.monitor.v2_0.PerfDataBuffer.synchWithTarget(PerfDataBuffer.java:277)
> at sun.jvmstat.perfdata.monitor.v2_0.PerfDataBuffer.buildMonitorMap(PerfDataBuffer.java:131)
> at sun.jvmstat.perfdata.monitor.PerfDataBufferImpl.findByName(PerfDataBufferImpl.java:241)
> at sun.jvmstat.perfdata.monitor.AbstractPerfDataBuffer.findByName(AbstractPerfDataBuffer.java:100)
> at sun.jvmstat.perfdata.monitor.AbstractMonitoredVm.findByName(AbstractMonitoredVm.java:85)
> at sun.jvmstat.monitor.MonitoredVmUtil.jvmArgs(MonitoredVmUtil.java:145)
> 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.jboss.tools.common.jdt.debug.tools.internal.Tools.getJvmArgs(Tools.java:780)
> at org.jboss.tools.common.jdt.debug.tools.ToolsCore.getJvmArgs(ToolsCore.java:98)
> at org.jboss.tools.common.jdt.debug.RemoteDebugActivator.getVmModelsUsingTools(RemoteDebugActivator.java:166)
> at org.jboss.tools.common.jdt.debug.RemoteDebugActivator.getVmModel(RemoteDebugActivator.java:145)
> at org.jboss.tools.common.jdt.debug.RemoteDebugActivator.getVmModels(RemoteDebugActivator.java:132)
> at org.jboss.tools.common.jdt.debug.RemoteDebugActivator.getDebugModels(RemoteDebugActivator.java:193)
> at org.jboss.tools.common.jdt.debug.RemoteDebugActivator.getDebugModels(RemoteDebugActivator.java:227)
> at org.jboss.tools.common.jdt.debug.ui.RemoteDebugUIActivator.discoverRemoteApplication(RemoteDebugUIActivator.java:137)
> at org.jboss.tools.common.jdt.debug.ui.RemoteDebugUIActivator$1.run(RemoteDebugUIActivator.java:93)
> at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 11 months