[JBoss JIRA] (JBDS-3278) OpenShift v3
by Andre Dietisheim (JIRA)
[ https://issues.jboss.org/browse/JBDS-3278?page=com.atlassian.jira.plugin.... ]
Andre Dietisheim updated JBDS-3278:
-----------------------------------
Fix Version/s: 9.0.0.GA
> OpenShift v3
> ------------
>
> Key: JBDS-3278
> URL: https://issues.jboss.org/browse/JBDS-3278
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Feature Request
> Components: openshift
> Reporter: Burr Sutter
> Assignee: Andre Dietisheim
> Fix For: 9.0.0.GA
>
>
> As an OpenShift v3 end-user, I need to be deploy, undeploy, add, remove, view logs, etc. for applications targeting the v3 API.
> The UI for OpenShift Explorer will need to be expanded (or replaced) to handle v3's new terminology and architecture.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 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] that's weird cause I'm not able to reproduce this on my machine :-(
The only problem I have is (1) from my previous comment. Here is my fedora info !fedora.png|thumbnail!
Could you possibly try to reproduce this issue on another machine? is libwebkitgtk was installed correctly - http://tools.jboss.org/documentation/faq/browsersim.html#platform-specifi... ?
> 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: browsersim, 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
> Fix For: 4.3.0.Alpha1
>
> Attachments: fedora.png, webkit.png
>
>
> 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)
11 years, 3 months
[JBoss JIRA] (JBIDE-3235) Missing properties view for servers elements
by Rob Stryker (JIRA)
[ https://issues.jboss.org/browse/JBIDE-3235?page=com.atlassian.jira.plugin... ]
Rob Stryker commented on JBIDE-3235:
------------------------------------
Just tested the one line patch to see if it worked, and, it doesn't. Unfortunately, double-click fires two separate events in common nav. First is the double-click listeners, and second is the "open" action. Somewhere along the way, the viewer resets itself. But for some reason the enter-key itself will work properly, but not the double-click.
I don't think this is doable by simply changing the double click action anymore.
> Missing properties view for servers elements
> --------------------------------------------
>
> Key: JBIDE-3235
> URL: https://issues.jboss.org/browse/JBIDE-3235
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: server
> Reporter: Max Rydahl Andersen
> Assignee: Max Rydahl Andersen
> Priority: Minor
> Fix For: 3.3.x
>
>
> Before I could directly edit properties for ports in properties view.
> Now I need to right click and choose Change Value and get a non-standard edit in the tree.
> This I could probably live with if I could just double click the value and edit it like in properties view.
> Properties view was though also nice to give other details than just access to edit.
> i.e.. I could copy values to get the value of file names etc. I can't copy elements from the tree and get a textual representation.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (JBDS-3282) Screencasts: OpenShift v3
by Andre Dietisheim (JIRA)
[ https://issues.jboss.org/browse/JBDS-3282?page=com.atlassian.jira.plugin.... ]
Andre Dietisheim updated JBDS-3282:
-----------------------------------
Fix Version/s: 9.0.0.GA
> Screencasts: OpenShift v3
> -------------------------
>
> Key: JBDS-3282
> URL: https://issues.jboss.org/browse/JBDS-3282
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Feature Request
> Components: openshift
> Reporter: Burr Sutter
> Assignee: Andre Dietisheim
> Fix For: 9.0.0.GA
>
>
> A series of short (5 minutes), educational videos to illustrate the new capabilities of JBDS associated with OpenShift.
> Including:
> - OpenShift's new web UI
> - OpenShift Explorer in the context of v3
> - perhaps an overview of Kubernetes, depends on how "pods" become visible to our end-user
> - an overview of Docker, depends on how 'containers" become visible to our end-user
> and all the typical start, stop, add, delete/remove, view logs, set env vars, etc.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (JBIDE-15135) Attach metadata during assembly instead of publish time
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-15135?page=com.atlassian.jira.plugi... ]
Nick Boldt commented on JBIDE-15135:
------------------------------------
{quote}generate for example a site for openshift module with the mojo, so that buildinfo.json exists, then try to build central similarily{quote}
So for the aggregate sites (site, coretests, webtools, hibernatetools) we'd get all the upstream projects in that section. Cool - that's perfect.
Re: defaults vs. CLI, the idea is to not have to deduce stuff after the fact (like a month later) but rather store the info when we know it (at build/publish time). That way it's there for archival purposes and future audit needs. Which is also why I think having JVM/OS details for the slaves is useful - it's easier to read the report than to have to go query the slave name for its details, or have to SSH there to get a list of JDKs available ... and then have to guess/assume which is the one used. Many slaves use a "latest" symlink and therefore when you go look at the slave a week after a build, if a new JDK update is released, your assumed JDK version will be wrong if IT/Engops updated the symlink between the time you built and the time you went to check for the info.
Same goes for deducing variables in parent pom... what if the parent pom in Nexus changes after the build?
> Attach metadata during assembly instead of publish time
> -------------------------------------------------------
>
> Key: JBIDE-15135
> URL: https://issues.jboss.org/browse/JBIDE-15135
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: build
> Reporter: Mickael Istria
> Assignee: Mickael Istria
> Fix For: 4.2.x
>
>
> In order to make it easier to deal with Nexus and to have an homogeneous way to access build metadata (commit id), it would be interesting to move creation of metadata at assembly time (same time as when we create index and so on), and put it directly into the site.
> Then whether we use Nexus or a home-made publication, we are sure that we can access metadata whenever we can access the binaries.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (JBIDE-18995) Early Access features can be installed from JBoss Tools p2 repository even if 'Enable Early Access' is disabled in Central
by Mickael Istria (JIRA)
[ https://issues.jboss.org/browse/JBIDE-18995?page=com.atlassian.jira.plugi... ]
Mickael Istria commented on JBIDE-18995:
----------------------------------------
What's your detailed procedure to install everything from JBoss stable p2 repo and reproduce this bug?
By default, main JBT site should not contain anything that is early-access. This kind of situation can have 2 reasons: bad entry in the early-access listing, or bad artifacts in JBT stable site?
> Early Access features can be installed from JBoss Tools p2 repository even if 'Enable Early Access' is disabled in Central
> --------------------------------------------------------------------------------------------------------------------------
>
> Key: JBIDE-18995
> URL: https://issues.jboss.org/browse/JBIDE-18995
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: updatesite
> Affects Versions: 4.2.1.Final
> Reporter: Denis Golovin
> Assignee: Mickael Istria
> Priority: Minor
> Attachments: ea-disabled.png, ea-installed.png
>
>
> I noticed central has "(Early Access Installed)" sign in after I installed everything from JBos Tools stable p2 repository.
> !ea-installed.png!
> "Enable Early Access" checkbox is not set by default in Central Editor
> !ea-disabled.png!
> This means I bypassed warning dialog in this scenario.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 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 updated JBIDE-18979:
--------------------------------
Attachment: fedora.png
> 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: browsersim, 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
> Fix For: 4.3.0.Alpha1
>
> Attachments: fedora.png, webkit.png
>
>
> 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)
11 years, 3 months
[JBoss JIRA] (JBIDE-15135) Attach metadata during assembly instead of publish time
by Mickael Istria (JIRA)
[ https://issues.jboss.org/browse/JBIDE-15135?page=com.atlassian.jira.plugi... ]
Mickael Istria commented on JBIDE-15135:
----------------------------------------
{quote}When is it available? How is it made available? How do you test this offline? How does the mojo know about upstream projects, since none of the jobs are linked in Jenkins?{quote}
The mojo looks at the site referenced as "repositories" with layout type "p2" in the current reactor. Then it looks for a file ${repositoryUrl}/buildinfo.json for each referenced repository.
To test it, generate for example a site for openshift module with the mojo, so that buildinfo.json exists, then try to build central similarily, but overriding the location for openshift to local one on filesystem. You'll see the upstream block will include some data from openshift.
{quote}Why not also dump variables we know are important which are resolved from parent pom? Why only worry about CLI variables, not defaults too?{quote}
The default ones can be deduced from that parent pom so I don't believe it's necessary to repeat them here. But if you think it's important, we can have a "cliOptions" block with the current behaviour, and a resolvedMavenProperties block with the main properties.
{quote} Is it a lot of work to collect that information? {quote}
I'm not concerned about the difficulty of collecting information, but more about giving interesting and easy to read reports. Being greedy in reports makes them more difficult to read. My strategy is to put them in only if we use them regularly, not if we may need it sometimes.
But if it's a blocker for you, I'm fine with adding JVM and OS info to the report.
> Attach metadata during assembly instead of publish time
> -------------------------------------------------------
>
> Key: JBIDE-15135
> URL: https://issues.jboss.org/browse/JBIDE-15135
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: build
> Reporter: Mickael Istria
> Assignee: Mickael Istria
> Fix For: 4.2.x
>
>
> In order to make it easier to deal with Nexus and to have an homogeneous way to access build metadata (commit id), it would be interesting to move creation of metadata at assembly time (same time as when we create index and so on), and put it directly into the site.
> Then whether we use Nexus or a home-made publication, we are sure that we can access metadata whenever we can access the binaries.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months