[JBoss JIRA] (JBIDE-18678) Make dependencies to org.jboss.tools.usage optional
by Kaloyan Raev (JIRA)
[ https://issues.jboss.org/browse/JBIDE-18678?page=com.atlassian.jira.plugi... ]
Kaloyan Raev commented on JBIDE-18678:
--------------------------------------
I pushed another pull request: https://github.com/jbosstools/jbosstools-base/pull/364
The change is only in the org.jboss.tools.usage bundle is backward compatible as long as the clients use only non-internal classes from the org.jboss.tools.usage bundle.
If this pull requested is accepted then the two previous ones in browsersim and aerogear won't be needed anymore.
> Make dependencies to org.jboss.tools.usage optional
> ---------------------------------------------------
>
> Key: JBIDE-18678
> URL: https://issues.jboss.org/browse/JBIDE-18678
> Project: Tools (JBoss Tools)
> Issue Type: Enhancement
> Components: browsersim, usage
> Affects Versions: 4.2.0.CR1
> Reporter: Kaloyan Raev
> Assignee: Alexey Kazakov
> Fix For: 4.3.x
>
>
> I am interested in adopting the CordovaSim feature in our product. However, most of the browsersim bundles have a strong dependency to org.jboss.tools.usage bundle, which force a Usage Reporting popup on startup. I want to avoid this and have the org.jboss.tools.usage excluded from my build.
> Is it possible to make the dependencies to org.jboss.tools.usage optional?
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
10 years, 10 months
[JBoss JIRA] (JBDS-3297) Download/Import Existing OpenShift Project
by Burr Sutter (JIRA)
[ https://issues.jboss.org/browse/JBDS-3297?page=com.atlassian.jira.plugin.... ]
Burr Sutter updated JBDS-3297:
------------------------------
Description:
Use Case #1 - Download/Import Existing OpenShift Project
a) Assume OpenShift is started remotely and provides an entrypoint URL (e.g. http://localhost:8080/osapi/v1beta1/projects)
b) Assume end-user is logged in (ignore auth for now)
c) Assume OpenShift already has some deployed "projects", this "project" definition includes the buildconfig, deployconfig, docker image, source git URL, routes and services.
d) Eclipse user will open a dialog and enter the URL from step a
e) Eclipse user will see a list of "things" associated with "projects" from step 1c
"things"
f) Embedded in one of those things is a Git URL - that will be displayed to the user who will agree to git clone it [1f]
g) If the downloaded items include a Maven project, the Eclipse user will see a newly configured Eclipse project based on Maven with the appropriately configured facets
h) If there is no pom.xml, the Eclipse user will see a newly configured generic Eclipse project containing the downloaded files
i) It is expected that a Maven-based Java project will build locally (leveraging Maven Central and/or maven.repository.redhat.com)
j) It is expected that a Maven-based Java project will deploy to a localhost EAP/Wildfly or a locally running Docker container:
docker run -it -p 8080:8080 openshift/wildfly-8-centos
[1f] https://github.com/openshift/origin/blob/master/examples/sample-app/appli...
was:
Use Case #1 - Download/Import Existing OpenShift Project
a) Assume OpenShift is started remotely and provides an entrypoint URL
b) Assume end-user is logged in (ignore auth for now)
c) Assume OpenShift already has some deployed "projects", this "project" definition includes the buildconfig, deployconfig, docker image, source git URL, routes and services.
d) Eclipse user will open a dialog and enter the URL from step a
e) Eclipse user will see a list of "things" associated with "projects" from step 1c
"things"
f) Embedded in one of those things is a Git URL - that will be displayed to the user who will agree to git clone it [1f]
g) If the downloaded items include a Maven project, the Eclipse user will see a newly configured Eclipse project based on Maven with the appropriately configured facets
h) If there is no pom.xml, the Eclipse user will see a newly configured generic Eclipse project containing the downloaded files
i) It is expected that a Maven-based Java project will build locally (leveraging Maven Central and/or maven.repository.redhat.com)
j) It is expected that a Maven-based Java project will deploy to a localhost EAP/Wildfly or a locally running Docker container:
docker run -it -p 8080:8080 openshift/wildfly-8-centos
[1f] https://github.com/openshift/origin/blob/master/examples/sample-app/appli...
> Download/Import Existing OpenShift Project
> ------------------------------------------
>
> Key: JBDS-3297
> URL: https://issues.jboss.org/browse/JBDS-3297
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Feature Request
> Components: openshift
> Reporter: Burr Sutter
> Assignee: Max Rydahl Andersen
>
> Use Case #1 - Download/Import Existing OpenShift Project
> a) Assume OpenShift is started remotely and provides an entrypoint URL (e.g. http://localhost:8080/osapi/v1beta1/projects)
> b) Assume end-user is logged in (ignore auth for now)
> c) Assume OpenShift already has some deployed "projects", this "project" definition includes the buildconfig, deployconfig, docker image, source git URL, routes and services.
> d) Eclipse user will open a dialog and enter the URL from step a
> e) Eclipse user will see a list of "things" associated with "projects" from step 1c
> "things"
> f) Embedded in one of those things is a Git URL - that will be displayed to the user who will agree to git clone it [1f]
> g) If the downloaded items include a Maven project, the Eclipse user will see a newly configured Eclipse project based on Maven with the appropriately configured facets
> h) If there is no pom.xml, the Eclipse user will see a newly configured generic Eclipse project containing the downloaded files
> i) It is expected that a Maven-based Java project will build locally (leveraging Maven Central and/or maven.repository.redhat.com)
> j) It is expected that a Maven-based Java project will deploy to a localhost EAP/Wildfly or a locally running Docker container:
> docker run -it -p 8080:8080 openshift/wildfly-8-centos
> [1f] https://github.com/openshift/origin/blob/master/examples/sample-app/appli...
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
10 years, 10 months
[JBoss JIRA] (JBDS-3298) Push changes to Existing OpenShift Project
by Burr Sutter (JIRA)
[ https://issues.jboss.org/browse/JBDS-3298?page=com.atlassian.jira.plugin.... ]
Burr Sutter updated JBDS-3298:
------------------------------
Description:
Use Case #2 Push changes to Existing OpenShift Project
a) assumes the steps in Use Case #1 JBDS-3297
b) assumes the end-user has uploaded his SSH keys (to allow for git push)
c) Eclipse user will add, edit and delete files from the originally downloaded/imported set of files - leveraging Eclipse specialized editors, content-assist, etc
d) Eclipse user will run (deploy) Maven-based Java projects on a local EAP
e) Eclipse user will test (JUnit, Arquillian)
f) Eclipse user will debug with the local EAP (run on localhost or from Docker Image)
g) Eclipse user will git add and git commit as appropriate
h) Eclipse user will git push to the original URL provided in Use Case #1
i) Eclipse user will await the automatic rebuild of a new image, deployment of the same
j) Eclipse user will then be provided a URL and the browser can be opened automatically
Note:
i) auto-build=true, auto-deploy=true
assumes the auto-build (.war and docker image) upon git push enabled in Use Case #1c (JBDS-3297). This step also assumes the auto-deploy upon build is enabled in 1c.
A future variation of #2 should allow for "auto-build=false" and "auto-deploy=true" with hot deployment of the binary .war or .ear.
If auto-build=false and auto-deploy=false then the Eclipse user will simply receive a message that his git push was successful, no URL, no browser opening.
was:
Use Case #2 Push changes to Existing OpenShift Project
a) assumes the steps in Use Case #1 JBDS-3297
b) assumes the end-user has uploaded his SSH keys (to allow for git push)
c) Eclipse user will add, edit and delete files from the originally downloaded/imported set of files - leveraging Eclipse specialized editors, content-assist, etc
d) Eclipse user will run (deploy) Maven-based Java projects on a local EAP
e) Eclipse user will test (JUnit, Arquillian)
f) Eclipse user will debug with the local EAP (run on localhost or from Docker Image)
g) Eclipse user will git add and git commit as appropriate
h) Eclipse user will git push to the original URL provided in Use Case #1
i) Eclipse user will await the automatic rebuild of a new image, deployment of the same
j) Eclipse user will then be provided a URL and the browser can be opened automatically
Note:
i) auto-build=true, auto-deploy=true
assumes the auto-build (.war and docker image) upon git push enabled in Use Case #1c (JBDS-3297). This step also assumes the auto-deploy upon build is enabled in 1c.
A future variation of #2 will allow for "auto-build=false" and "auto-deploy=true" with hot deployment of the binary .war or .ear.
> Push changes to Existing OpenShift Project
> ------------------------------------------
>
> Key: JBDS-3298
> URL: https://issues.jboss.org/browse/JBDS-3298
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Feature Request
> Components: openshift
> Reporter: Burr Sutter
> Assignee: Max Rydahl Andersen
>
> Use Case #2 Push changes to Existing OpenShift Project
> a) assumes the steps in Use Case #1 JBDS-3297
> b) assumes the end-user has uploaded his SSH keys (to allow for git push)
> c) Eclipse user will add, edit and delete files from the originally downloaded/imported set of files - leveraging Eclipse specialized editors, content-assist, etc
> d) Eclipse user will run (deploy) Maven-based Java projects on a local EAP
> e) Eclipse user will test (JUnit, Arquillian)
> f) Eclipse user will debug with the local EAP (run on localhost or from Docker Image)
> g) Eclipse user will git add and git commit as appropriate
> h) Eclipse user will git push to the original URL provided in Use Case #1
> i) Eclipse user will await the automatic rebuild of a new image, deployment of the same
> j) Eclipse user will then be provided a URL and the browser can be opened automatically
> Note:
> i) auto-build=true, auto-deploy=true
> assumes the auto-build (.war and docker image) upon git push enabled in Use Case #1c (JBDS-3297). This step also assumes the auto-deploy upon build is enabled in 1c.
> A future variation of #2 should allow for "auto-build=false" and "auto-deploy=true" with hot deployment of the binary .war or .ear.
> If auto-build=false and auto-deploy=false then the Eclipse user will simply receive a message that his git push was successful, no URL, no browser opening.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
10 years, 10 months
[JBoss JIRA] (JBDS-3297) Download/Import Existing OpenShift Project
by Burr Sutter (JIRA)
[ https://issues.jboss.org/browse/JBDS-3297?page=com.atlassian.jira.plugin.... ]
Burr Sutter updated JBDS-3297:
------------------------------
Description:
Use Case #1 - Download/Import Existing OpenShift Project
a) Assume OpenShift is started remotely and provides an entrypoint URL
b) Assume end-user is logged in (ignore auth for now)
c) Assume OpenShift already has some deployed "projects", this "project" definition includes the buildconfig, deployconfig, docker image, source git URL, routes and services.
d) Eclipse user will open a dialog and enter the URL from step a
e) Eclipse user will see a list of "things" associated with "projects" from step 1c
"things"
f) Embedded in one of those things is a Git URL - that will be displayed to the user who will agree to git clone it [1f]
g) If the downloaded items include a Maven project, the Eclipse user will see a newly configured Eclipse project based on Maven with the appropriately configured facets
h) If there is no pom.xml, the Eclipse user will see a newly configured generic Eclipse project containing the downloaded files
i) It is expected that a Maven-based Java project will build locally (leveraging Maven Central and/or maven.repository.redhat.com)
j) It is expected that a Maven-based Java project will deploy to a localhost EAP/Wildfly or a locally running Docker container:
docker run -it -p 8080:8080 openshift/wildfly-8-centos
[1f] https://github.com/openshift/origin/blob/master/examples/sample-app/appli...
was:
Use Case #1 - Download/Import Existing OpenShift Project
a) Assume OpenShift is started remotely and provides an entrypoint URL
b) Assume end-user is logged in (ignore auth for now)
c) Assume OpenShift already has some deployed "projects", this "project" definition includes the buildconfig, deployconfig, docker image, source git URL, routes and services.
d) Eclipse user will open a dialog and enter the URL from step a
e) Eclipse user will see a list of "things" associated with "projects" from step 1c
"things"
f) Embedded in one of those things is a Git URL - that will be displayed to the user who will agree to "download" or git clone it
g) If the downloaded items include a Maven project, the Eclipse user will see a newly configured Eclipse project based on Maven with the appropriately configured facets
h) If there is no pom.xml, the Eclipse user will see a newly configured generic Eclipse project containing the downloaded files
i) It is expected that a Maven-based Java project will build locally (leveraging Maven Central and/or maven.repository.redhat.com)
j) It is expected that a Maven-based Java project will deploy to a localhost EAP/Wildfly or a locally running Docker container:
docker run -it -p 8080:8080 openshift/wildfly-8-centos
> Download/Import Existing OpenShift Project
> ------------------------------------------
>
> Key: JBDS-3297
> URL: https://issues.jboss.org/browse/JBDS-3297
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Feature Request
> Components: openshift
> Reporter: Burr Sutter
> Assignee: Max Rydahl Andersen
>
> Use Case #1 - Download/Import Existing OpenShift Project
> a) Assume OpenShift is started remotely and provides an entrypoint URL
> b) Assume end-user is logged in (ignore auth for now)
> c) Assume OpenShift already has some deployed "projects", this "project" definition includes the buildconfig, deployconfig, docker image, source git URL, routes and services.
> d) Eclipse user will open a dialog and enter the URL from step a
> e) Eclipse user will see a list of "things" associated with "projects" from step 1c
> "things"
> f) Embedded in one of those things is a Git URL - that will be displayed to the user who will agree to git clone it [1f]
> g) If the downloaded items include a Maven project, the Eclipse user will see a newly configured Eclipse project based on Maven with the appropriately configured facets
> h) If there is no pom.xml, the Eclipse user will see a newly configured generic Eclipse project containing the downloaded files
> i) It is expected that a Maven-based Java project will build locally (leveraging Maven Central and/or maven.repository.redhat.com)
> j) It is expected that a Maven-based Java project will deploy to a localhost EAP/Wildfly or a locally running Docker container:
> docker run -it -p 8080:8080 openshift/wildfly-8-centos
> [1f] https://github.com/openshift/origin/blob/master/examples/sample-app/appli...
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
10 years, 10 months
[JBoss JIRA] (JBDS-3298) Push changes to Existing OpenShift Project
by CDW Engine (JIRA)
[ https://issues.jboss.org/browse/JBDS-3298?page=com.atlassian.jira.plugin.... ]
CDW Engine updated JBDS-3298:
-----------------------------
CDW pm_ack: ?
CDW release: ?
> Push changes to Existing OpenShift Project
> ------------------------------------------
>
> Key: JBDS-3298
> URL: https://issues.jboss.org/browse/JBDS-3298
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Feature Request
> Components: openshift
> Reporter: Burr Sutter
> Assignee: Max Rydahl Andersen
>
> Use Case #2 Push changes to Existing OpenShift Project
> a) assumes the steps in Use Case #1 JBDS-3297
> b) assumes the end-user has uploaded his SSH keys (to allow for git push)
> c) Eclipse user will add, edit and delete files from the originally downloaded/imported set of files - leveraging Eclipse specialized editors, content-assist, etc
> d) Eclipse user will run (deploy) Maven-based Java projects on a local EAP
> e) Eclipse user will test (JUnit, Arquillian)
> f) Eclipse user will debug with the local EAP (run on localhost or from Docker Image)
> g) Eclipse user will git add and git commit as appropriate
> h) Eclipse user will git push to the original URL provided in Use Case #1
> i) Eclipse user will await the automatic rebuild of a new image, deployment of the same
> j) Eclipse user will then be provided a URL and the browser can be opened automatically
> Note:
> i) auto-build=true, auto-deploy=true
> assumes the auto-build (.war and docker image) upon git push enabled in Use Case #1c (JBDS-3297). This step also assumes the auto-deploy upon build is enabled in 1c.
> A future variation of #2 will allow for "auto-build=false" and "auto-deploy=true" with hot deployment of the binary .war or .ear.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
10 years, 10 months
[JBoss JIRA] (JBDS-3298) Push changes to Existing OpenShift Project
by Burr Sutter (JIRA)
Burr Sutter created JBDS-3298:
---------------------------------
Summary: Push changes to Existing OpenShift Project
Key: JBDS-3298
URL: https://issues.jboss.org/browse/JBDS-3298
Project: Developer Studio (JBoss Developer Studio)
Issue Type: Feature Request
Components: openshift
Reporter: Burr Sutter
Assignee: Max Rydahl Andersen
Use Case #2 Push changes to Existing OpenShift Project
a) assumes the steps in Use Case #1 JBDS-3297
b) assumes the end-user has uploaded his SSH keys (to allow for git push)
c) Eclipse user will add, edit and delete files from the originally downloaded/imported set of files - leveraging Eclipse specialized editors, content-assist, etc
d) Eclipse user will run (deploy) Maven-based Java projects on a local EAP
e) Eclipse user will test (JUnit, Arquillian)
f) Eclipse user will debug with the local EAP (run on localhost or from Docker Image)
g) Eclipse user will git add and git commit as appropriate
h) Eclipse user will git push to the original URL provided in Use Case #1
i) Eclipse user will await the automatic rebuild of a new image, deployment of the same
j) Eclipse user will then be provided a URL and the browser can be opened automatically
Note:
i) auto-build=true, auto-deploy=true
assumes the auto-build (.war and docker image) upon git push enabled in Use Case #1c (JBDS-3297). This step also assumes the auto-deploy upon build is enabled in 1c.
A future variation of #2 will allow for "auto-build=false" and "auto-deploy=true" with hot deployment of the binary .war or .ear.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
10 years, 10 months
[JBoss JIRA] (JBDS-3297) Download/Import Existing OpenShift Project
by CDW Engine (JIRA)
[ https://issues.jboss.org/browse/JBDS-3297?page=com.atlassian.jira.plugin.... ]
CDW Engine updated JBDS-3297:
-----------------------------
CDW pm_ack: ?
CDW release: ?
> Download/Import Existing OpenShift Project
> ------------------------------------------
>
> Key: JBDS-3297
> URL: https://issues.jboss.org/browse/JBDS-3297
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Feature Request
> Components: openshift
> Reporter: Burr Sutter
> Assignee: Max Rydahl Andersen
>
> Use Case #1 - Download/Import Existing OpenShift Project
> a) Assume OpenShift is started remotely and provides an entrypoint URL
> b) Assume end-user is logged in (ignore auth for now)
> c) Assume OpenShift already has some deployed "projects", this "project" definition includes the buildconfig, deployconfig, docker image, source git URL, routes and services.
> d) Eclipse user will open a dialog and enter the URL from step a
> e) Eclipse user will see a list of "things" associated with "projects" from step 1c
> "things"
> f) Embedded in one of those things is a Git URL - that will be displayed to the user who will agree to "download" or git clone it
> g) If the downloaded items include a Maven project, the Eclipse user will see a newly configured Eclipse project based on Maven with the appropriately configured facets
> h) If there is no pom.xml, the Eclipse user will see a newly configured generic Eclipse project containing the downloaded files
> i) It is expected that a Maven-based Java project will build locally (leveraging Maven Central and/or maven.repository.redhat.com)
> j) It is expected that a Maven-based Java project will deploy to a localhost EAP/Wildfly or a locally running Docker container:
> docker run -it -p 8080:8080 openshift/wildfly-8-centos
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
10 years, 10 months
[JBoss JIRA] (JBDS-3297) Download/Import Existing OpenShift Project
by Burr Sutter (JIRA)
Burr Sutter created JBDS-3297:
---------------------------------
Summary: Download/Import Existing OpenShift Project
Key: JBDS-3297
URL: https://issues.jboss.org/browse/JBDS-3297
Project: Developer Studio (JBoss Developer Studio)
Issue Type: Feature Request
Components: openshift
Reporter: Burr Sutter
Assignee: Max Rydahl Andersen
Use Case #1 - Download/Import Existing OpenShift Project
a) Assume OpenShift is started remotely and provides an entrypoint URL
b) Assume end-user is logged in (ignore auth for now)
c) Assume OpenShift already has some deployed "projects", this "project" definition includes the buildconfig, deployconfig, docker image, source git URL, routes and services.
d) Eclipse user will open a dialog and enter the URL from step a
e) Eclipse user will see a list of "things" associated with "projects" from step 1c
"things"
f) Embedded in one of those things is a Git URL - that will be displayed to the user who will agree to "download" or git clone it
g) If the downloaded items include a Maven project, the Eclipse user will see a newly configured Eclipse project based on Maven with the appropriately configured facets
h) If there is no pom.xml, the Eclipse user will see a newly configured generic Eclipse project containing the downloaded files
i) It is expected that a Maven-based Java project will build locally (leveraging Maven Central and/or maven.repository.redhat.com)
j) It is expected that a Maven-based Java project will deploy to a localhost EAP/Wildfly or a locally running Docker container:
docker run -it -p 8080:8080 openshift/wildfly-8-centos
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
10 years, 10 months
[JBoss JIRA] (JBIDE-18979) Unable to run CordovaSim with Fedora 21 KDE
by Ilya Buziuk (JIRA)
[ https://issues.jboss.org/browse/JBIDE-18979?page=com.atlassian.jira.plugi... ]
Ilya Buziuk commented on JBIDE-18979:
-------------------------------------
[~vpakan] issue seems to be coupled with swt. I do believe that libwebkitgtk-3.0.so.0 and libwebkitgtk-1.0.so.0 are installed correctly.
Installing Fedora 21 KDE - will try to figure it out
> Unable to run CordovaSim with Fedora 21 KDE
> -------------------------------------------
>
> Key: JBIDE-18979
> URL: https://issues.jboss.org/browse/JBIDE-18979
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: cordovasim
> Affects Versions: 4.2.1.Final
> Environment: JBDS 8.0.1.CR1-v20141207-0100-B352, Java Oracle 1.8
> Fedora 21 KDE 64 bit
> Reporter: Vlado Pakan
> Assignee: Ilya Buziuk
> Priority: Critical
>
> 1. Run default Hybrid Mobile app with CordovaSim
> {noformat}
> No bp log location saved, using default.
> [000:000] Cpu: 6.42.7, x4, 3500Mhz, 7867MB
> [000:000] Computer model: Not available
> [000:000] Browser XEmbed support present: 1
> [000:000] Browser toolkit is Gtk2.
> [000:003] Using Gtk2 toolkit
> No bp log location saved, using default.
> [000:000] Cpu: 6.42.7, x4, 3500Mhz, 7867MB
> [000:001] Computer model: Not available
> [000:497] Warning(optionsfile.cc:30): Load: Could not open file, err=2
> [000:497] No bp log location saved, using default.
> [000:497] Cpu: 6.42.7, x4, 3500Mhz, 7867MB
> [000:497] Computer model: Not available
> [000:498] Browser XEmbed support present: 1
> [000:498] Browser toolkit is Gtk2.
> [000:498] Using Gtk2 toolkit
> [000:003] Warning(optionsfile.cc:30): Load: Could not open file, err=2
> [000:003] No bp log location saved, using default.
> [000:004] Cpu: 6.42.7, x4, 3500Mhz, 7867MB
> [000:004] Computer model: Not available
> (SWT:13580): GLib-GObject-CRITICAL **: g_closure_unref: assertion 'closure->ref_count > 0' failed
> (SWT:13580): GLib-GObject-CRITICAL **: g_closure_unref: assertion 'closure->ref_count > 0' failed
> (SWT:13580): GLib-GObject-CRITICAL **: g_closure_unref: assertion 'closure->ref_count > 0' failed
> (SWT:13580): GLib-GObject-CRITICAL **: g_closure_unref: assertion 'closure->ref_count > 0' failed
> (SWT:13580): GLib-GObject-CRITICAL **: g_closure_unref: assertion 'closure->ref_count > 0' failed
> (SWT:13580): GLib-GObject-CRITICAL **: g_closure_unref: assertion 'closure->ref_count > 0' failed
> (SWT:13580): GLib-GObject-CRITICAL **: g_closure_unref: assertion 'closure->ref_count > 0' failed
> (SWT:13580): GLib-GObject-CRITICAL **: g_closure_unref: assertion 'closure->ref_count > 0' failed
> #
> # A fatal error has been detected by the Java Runtime Environment:
> #
> # SIGSEGV (0xb) at pc=0x000000370a80c42b, pid=13580, tid=140558422947584
> #
> # JRE version: Java(TM) SE Runtime Environment (8.0-b132) (build 1.8.0-b132)
> # Java VM: Java HotSpot(TM) 64-Bit Server VM (25.0-b70 mixed mode linux-amd64 compressed oops)
> # Problematic frame:
> # C [ld-linux-x86-64.so.2+0xc42b]
> #
> # Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
> #
> # An error report file with more information is saved as:
> # /home/vpakan/hs_err_pid13580.log
> #
> # If you would like to submit a bug report, please visit:
> # http://bugreport.sun.com/bugreport/crash.jsp
> # The crash happened outside the Java Virtual Machine in native code.
> # See problematic frame for where to report the bug.
> #
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
10 years, 10 months