[JBoss JIRA] (JBDS-4756) Cannot start devstudio on mac os with jdk 11
by Josef Kopriva (Jira)
[ https://issues.jboss.org/browse/JBDS-4756?page=com.atlassian.jira.plugin.... ]
Josef Kopriva updated JBDS-4756:
--------------------------------
Priority: Major (was: Critical)
> Cannot start devstudio on mac os with jdk 11
> --------------------------------------------
>
> Key: JBDS-4756
> URL: https://issues.jboss.org/browse/JBDS-4756
> Project: Red Hat CodeReady Studio (devstudio)
> Issue Type: Bug
> Components: installer
> Affects Versions: 12.11.0.AM1
> Reporter: Ondrej Dockal
> Assignee: Ondrej Dockal
> Priority: Major
> Fix For: 12.11.0.GA
>
> Attachments: Screenshot_20190204_115602.png
>
>
> I can easily install devstudio on mac os with default jdk 11 (from /qa/tools/opt/osx/jdk11_last) but I cannot make it start. No other errors or warnings except the one here:
> !Screenshot_20190204_115602.png|thumbnail!
> More info links [here|https://support.apple.com/kb/DL1572?locale=en_US].
> I can also see installer [tests|https://dev-platform-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/view/D...] failures on mac os 10.12 and 10.13 with this tack trace:
> {code}
> java.awt.HeadlessException
> at java.desktop/sun.awt.HeadlessToolkit.getScreenSize(HeadlessToolkit.java:186)
> at org.netbeans.jemmy.util.PNGEncoder.captureScreen(PNGEncoder.java:244)
> at org.netbeans.jemmy.util.PNGEncoder.captureScreen(PNGEncoder.java:237)
> at com.jboss.jbds.installer.test.InstallerTest.testInstall(InstallerTest.java:49)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44)
> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)
> at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
> at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
> at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31)
> at org.junit.runners.BlockJUnit4ClassRunner.runNotIgnored(BlockJUnit4ClassRunner.java:79)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:71)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:49)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184)
> at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
> at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:236)
> at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:53)
> at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:119)
> at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:101)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at org.apache.maven.surefire.booter.ProviderFactory$ClassLoaderProxy.invoke(ProviderFactory.java:103)
> at com.sun.proxy.$Proxy0.invoke(Unknown Source)
> at org.apache.maven.surefire.booter.SurefireStarter.invokeProvider(SurefireStarter.java:150)
> at org.apache.maven.surefire.booter.SurefireStarter.runSuitesInProcess(SurefireStarter.java:91)
> at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:69)
> {code}
> It might be possible to at least to try the installation and run on some bare metal to verify this error. Could someone possibly assist here, please? I have a suspicion that it might be performance related as the time needed to even open the jdk folder on the shared drive takes quite some time. Thanks!
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 9 months
[JBoss JIRA] (JBIDE-26602) Switching JDKs for EAP7.2 breaks EAP Launch configuration
by Josef Kopriva (Jira)
Josef Kopriva created JBIDE-26602:
-------------------------------------
Summary: Switching JDKs for EAP7.2 breaks EAP Launch configuration
Key: JBIDE-26602
URL: https://issues.jboss.org/browse/JBIDE-26602
Project: Tools (JBoss Tools)
Issue Type: Bug
Components: server
Affects Versions: 4.11.0.Final
Reporter: Josef Kopriva
Switching JDK for EAP7.2 results in wrong launch command for EAP.
The issue is with parameter: --add-exports=jdk.unsupported/sun.misc=ALL-UNNAMED
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 9 months
[JBoss JIRA] (JBIDE-26311) EAP 7.1 fails to stop when connected over ssh
by Josef Kopriva (Jira)
[ https://issues.jboss.org/browse/JBIDE-26311?page=com.atlassian.jira.plugi... ]
Josef Kopriva commented on JBIDE-26311:
---------------------------------------
UPDATE: If I use EAP 7.2 and do deploy before shutting down the server, shutdown works as expected, but If I start server and shutdown right away, then it fails.
> EAP 7.1 fails to stop when connected over ssh
> ---------------------------------------------
>
> Key: JBIDE-26311
> URL: https://issues.jboss.org/browse/JBIDE-26311
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: server
> Affects Versions: 4.9.0.AM2
> Reporter: Martin Malina
> Assignee: Rob Stryker
> Priority: Major
> Labels: regression
> Fix For: 4.11.x
>
> Attachments: JBIDE-26311.local.ogv
>
>
> I have an EAP 7.1 setup up over ssh. It's running on my localhost, so it's the most basic test of an ssh server. When I click the stop button on the server, it says:
> Server Red Hat JBoss EAP 7.1 ssh failed to stop.
> An exception stack trace is not available.
> It will stop on second attempt. On a local server this would mean killing the server java process. I'm not sure exactly what happens on a remote server, but it works.
> I'm pretty sure this worked last time (previous milestone).
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 9 months
[JBoss JIRA] (JBIDE-26582) Add support for Quarkus based applications
by Jeff MAURY (Jira)
[ https://issues.jboss.org/browse/JBIDE-26582?page=com.atlassian.jira.plugi... ]
Jeff MAURY commented on JBIDE-26582:
------------------------------------
I would like to see the same kind of support that we have for spring boot so no native in the first place
> Add support for Quarkus based applications
> ------------------------------------------
>
> Key: JBIDE-26582
> URL: https://issues.jboss.org/browse/JBIDE-26582
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: openshift
> Affects Versions: 4.11.0.Final
> Reporter: Jeff MAURY
> Priority: Major
> Fix For: 4.12.0.Final
>
>
> We should support JBoss Tools based inner loop for Quarkus based applications.
> In the first time support only OpenJDK based deployments as I'm not sure native image based deployments can support inner loop.
> That would also probably means an update of the openJDK base image
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 9 months
[JBoss JIRA] (JBIDE-26582) Add support for Quarkus based applications
by André Dietisheim (Jira)
[ https://issues.jboss.org/browse/JBIDE-26582?page=com.atlassian.jira.plugi... ]
André Dietisheim edited comment on JBIDE-26582 at 3/29/19 4:34 AM:
-------------------------------------------------------------------
[~jeffmaury] what is your vision for this support looking like? In my limited understanding native images would only run on linux, but the dev-mode hotcode replace might be something that we can support?
was (Author: adietish):
[~jeffmaury] what is your vision for this support looking like? As far as I understood so far native images would only run on linux, but the dev-mode hotcode replace might be something that we can support?
> Add support for Quarkus based applications
> ------------------------------------------
>
> Key: JBIDE-26582
> URL: https://issues.jboss.org/browse/JBIDE-26582
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: openshift
> Affects Versions: 4.11.0.Final
> Reporter: Jeff MAURY
> Priority: Major
> Fix For: 4.12.0.Final
>
>
> We should support JBoss Tools based inner loop for Quarkus based applications.
> In the first time support only OpenJDK based deployments as I'm not sure native image based deployments can support inner loop.
> That would also probably means an update of the openJDK base image
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 9 months
[JBoss JIRA] (JBIDE-26582) Add support for Quarkus based applications
by André Dietisheim (Jira)
[ https://issues.jboss.org/browse/JBIDE-26582?page=com.atlassian.jira.plugi... ]
André Dietisheim commented on JBIDE-26582:
------------------------------------------
[~jeffmaury] what is your vision for this support looking like? As far as I understood so far native images would only run on linux, but the dev-mode hotcode replace might be something that we can support?
> Add support for Quarkus based applications
> ------------------------------------------
>
> Key: JBIDE-26582
> URL: https://issues.jboss.org/browse/JBIDE-26582
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: openshift
> Affects Versions: 4.11.0.Final
> Reporter: Jeff MAURY
> Priority: Major
> Fix For: 4.12.0.Final
>
>
> We should support JBoss Tools based inner loop for Quarkus based applications.
> In the first time support only OpenJDK based deployments as I'm not sure native image based deployments can support inner loop.
> That would also probably means an update of the openJDK base image
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 9 months
[JBoss JIRA] (JBIDE-26599) LiveReload does not work with OpenShift3 server adapter
by André Dietisheim (Jira)
[ https://issues.jboss.org/browse/JBIDE-26599?page=com.atlassian.jira.plugi... ]
André Dietisheim commented on JBIDE-26599:
------------------------------------------
4.11.Final shipped, we went out of time for this unfortunately. Postponing.
> LiveReload does not work with OpenShift3 server adapter
> -------------------------------------------------------
>
> Key: JBIDE-26599
> URL: https://issues.jboss.org/browse/JBIDE-26599
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: livereload, openshift
> Affects Versions: 4.11.0.Final
> Environment: oc cluster up 3.11 from Fedora repo
> Openshift templates from: https://github.com/jboss-container-images/jboss-eap-7-openshift-image/tre...
> Devstudio + installed livereload:
> Version: 12.11.0.GA
> Build id: GA-v20190321-1925-B4244
> Build date: 20190321-1925
> JDK 11.02 + F29
> Reporter: Josef Kopriva
> Priority: Critical
> Fix For: 4.12.0.AM1
>
> Attachments: image-2019-03-27-10-30-34-801.png
>
>
> If I try to directly connect to livereload server there is an error message:
> {code:java}
> HTTP ERROR 500
> Problem accessing /. Reason:
> Server Error
> Caused by:
> java.lang.IllegalArgumentException: Invalid URI host: null (authority: null)
> at org.eclipse.jetty.client.HttpClient.checkHost(HttpClient.java:506)
> at org.eclipse.jetty.client.HttpClient.newHttpRequest(HttpClient.java:491)
> at org.eclipse.jetty.client.HttpClient.newRequest(HttpClient.java:449)
> at org.eclipse.jetty.client.HttpClient.newRequest(HttpClient.java:438)
> at org.eclipse.jetty.proxy.AsyncMiddleManServlet.service(AsyncMiddleManServlet.java:92)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:873)
> at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:542)
> at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:255)
> at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1701)
> at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:255)
> at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1345)
> at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:203)
> at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:480)
> at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1668)
> at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:201)
> at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1247)
> at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:144)
> at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)
> at org.eclipse.jetty.server.Server.handle(Server.java:502)
> at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:370)
> at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:267)
> at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:305)
> at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103)
> at org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:117)
> at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:765)
> at org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:683)
> at java.base/java.lang.Thread.run(Thread.java:834)
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 9 months
[JBoss JIRA] (JBIDE-26599) LiveReload does not work with OpenShift3 server adapter
by André Dietisheim (Jira)
[ https://issues.jboss.org/browse/JBIDE-26599?page=com.atlassian.jira.plugi... ]
André Dietisheim updated JBIDE-26599:
-------------------------------------
Fix Version/s: 4.12.0.AM1
(was: 4.11.0.Final)
> LiveReload does not work with OpenShift3 server adapter
> -------------------------------------------------------
>
> Key: JBIDE-26599
> URL: https://issues.jboss.org/browse/JBIDE-26599
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: livereload, openshift
> Affects Versions: 4.11.0.Final
> Environment: oc cluster up 3.11 from Fedora repo
> Openshift templates from: https://github.com/jboss-container-images/jboss-eap-7-openshift-image/tre...
> Devstudio + installed livereload:
> Version: 12.11.0.GA
> Build id: GA-v20190321-1925-B4244
> Build date: 20190321-1925
> JDK 11.02 + F29
> Reporter: Josef Kopriva
> Priority: Critical
> Fix For: 4.12.0.AM1
>
> Attachments: image-2019-03-27-10-30-34-801.png
>
>
> If I try to directly connect to livereload server there is an error message:
> {code:java}
> HTTP ERROR 500
> Problem accessing /. Reason:
> Server Error
> Caused by:
> java.lang.IllegalArgumentException: Invalid URI host: null (authority: null)
> at org.eclipse.jetty.client.HttpClient.checkHost(HttpClient.java:506)
> at org.eclipse.jetty.client.HttpClient.newHttpRequest(HttpClient.java:491)
> at org.eclipse.jetty.client.HttpClient.newRequest(HttpClient.java:449)
> at org.eclipse.jetty.client.HttpClient.newRequest(HttpClient.java:438)
> at org.eclipse.jetty.proxy.AsyncMiddleManServlet.service(AsyncMiddleManServlet.java:92)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:873)
> at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:542)
> at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:255)
> at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1701)
> at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:255)
> at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1345)
> at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:203)
> at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:480)
> at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1668)
> at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:201)
> at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1247)
> at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:144)
> at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)
> at org.eclipse.jetty.server.Server.handle(Server.java:502)
> at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:370)
> at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:267)
> at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:305)
> at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103)
> at org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:117)
> at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:765)
> at org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:683)
> at java.base/java.lang.Thread.run(Thread.java:834)
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 9 months
[JBoss JIRA] (JBDS-4756) Cannot start devstudio on mac os with jdk 11
by Ondrej Dockal (Jira)
[ https://issues.jboss.org/browse/JBDS-4756?page=com.atlassian.jira.plugin.... ]
Ondrej Dockal edited comment on JBDS-4756 at 3/28/19 5:01 PM:
--------------------------------------------------------------
I tried myself on the CCI mac (bigmek). Installation with jdk 11 went alright, but when trying to run the devstudio I gotthe same message. My guess is that this is caused by slow network access to jdk which resides on shared drive. (/qa/tools). I will validate my assumptions...
was (Author: odockal):
I tried myself on the CCI mac (bigmek). Installation with jdk 11 went alright, but when trying to run the devstudio I gotthe same message. My guess is that this is caused by slow network access to jdk which resides on shared drive. (/qa/tools). I will my validate my assumptions...
> Cannot start devstudio on mac os with jdk 11
> --------------------------------------------
>
> Key: JBDS-4756
> URL: https://issues.jboss.org/browse/JBDS-4756
> Project: Red Hat CodeReady Studio (devstudio)
> Issue Type: Bug
> Components: installer
> Affects Versions: 12.11.0.AM1
> Reporter: Ondrej Dockal
> Assignee: Ondrej Dockal
> Priority: Critical
> Fix For: 12.11.0.GA
>
> Attachments: Screenshot_20190204_115602.png
>
>
> I can easily install devstudio on mac os with default jdk 11 (from /qa/tools/opt/osx/jdk11_last) but I cannot make it start. No other errors or warnings except the one here:
> !Screenshot_20190204_115602.png|thumbnail!
> More info links [here|https://support.apple.com/kb/DL1572?locale=en_US].
> I can also see installer [tests|https://dev-platform-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/view/D...] failures on mac os 10.12 and 10.13 with this tack trace:
> {code}
> java.awt.HeadlessException
> at java.desktop/sun.awt.HeadlessToolkit.getScreenSize(HeadlessToolkit.java:186)
> at org.netbeans.jemmy.util.PNGEncoder.captureScreen(PNGEncoder.java:244)
> at org.netbeans.jemmy.util.PNGEncoder.captureScreen(PNGEncoder.java:237)
> at com.jboss.jbds.installer.test.InstallerTest.testInstall(InstallerTest.java:49)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44)
> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)
> at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
> at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
> at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31)
> at org.junit.runners.BlockJUnit4ClassRunner.runNotIgnored(BlockJUnit4ClassRunner.java:79)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:71)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:49)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184)
> at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
> at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:236)
> at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:53)
> at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:119)
> at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:101)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at org.apache.maven.surefire.booter.ProviderFactory$ClassLoaderProxy.invoke(ProviderFactory.java:103)
> at com.sun.proxy.$Proxy0.invoke(Unknown Source)
> at org.apache.maven.surefire.booter.SurefireStarter.invokeProvider(SurefireStarter.java:150)
> at org.apache.maven.surefire.booter.SurefireStarter.runSuitesInProcess(SurefireStarter.java:91)
> at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:69)
> {code}
> It might be possible to at least to try the installation and run on some bare metal to verify this error. Could someone possibly assist here, please? I have a suspicion that it might be performance related as the time needed to even open the jdk folder on the shared drive takes quite some time. Thanks!
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 9 months
[JBoss JIRA] (ERT-721) Create/update intern presentations
by Eric Williams (Jira)
Eric Williams created ERT-721:
---------------------------------
Summary: Create/update intern presentations
Key: ERT-721
URL: https://issues.jboss.org/browse/ERT-721
Project: Eclipse Release Train
Issue Type: Task
Reporter: Eric Williams
Assignee: Eric Williams
Work on intern committee related presentations/training materials. Update and review team talk with Xi.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 9 months