[JBoss JIRA] (JBDS-2866) CordovaSim Debugger
by Ilya Buziuk (JIRA)
[ https://issues.jboss.org/browse/JBDS-2866?page=com.atlassian.jira.plugin.... ]
Ilya Buziuk commented on JBDS-2866:
-----------------------------------
{quote}
I could have opened this debugger not only in Chrome but in any browser
{quote}
I was wrong here ^:
- it should be a webkit based browser;
- browser should have an appropriate websocket support.
The point is that Java 7 FX Web View doesn't have websocket support - https://javafx-jira.kenai.com/browse/RT-14947 . However it is fixed in JDK 8 Lombard. So, I believe that oracle JDK 8, that will be release on the 18th of March 2014 (according to the Oracle schedule), is a requirement for the debugger. I have tested it with early build of the JDK 8 on Windows https://jdk8.java.net/download.html - works fine
> CordovaSim Debugger
> -------------------
>
> Key: JBDS-2866
> URL: https://issues.jboss.org/browse/JBDS-2866
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: browsersim, requirements
> Reporter: Burr Sutter
> Assignee: Ilya Buziuk
>
> The current FireBug Lite in CordovaSim has the following limitations:
> 1) When using LiveReload, the window closes with every reload
> 2) Various "page load" events with console.log statements are not visible in FireBug Lite console, like having console.log() in your deviceready
> http://screencast.com/t/RRGhV9PV
> Note: I forgot to add the Console Cordova plugin, not sure if that is necessary but the window closes, so not sure how I would see the message
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 3 months
[JBoss JIRA] (JBIDE-16309) Move inter-JBT dependencies to component poms
by Mickael Istria (JIRA)
[ https://issues.jboss.org/browse/JBIDE-16309?page=com.atlassian.jira.plugi... ]
Mickael Istria commented on JBIDE-16309:
----------------------------------------
I'm not sure opening subtasks on all components will be more helpful than listing PRs on this bug, but if you believe it's better, feel free to do it.
> Move inter-JBT dependencies to component poms
> ---------------------------------------------
>
> Key: JBIDE-16309
> URL: https://issues.jboss.org/browse/JBIDE-16309
> Project: Tools (JBoss Tools)
> Issue Type: Enhancement
> Components: build
> Reporter: Mickael Istria
> Assignee: Mickael Istria
> Fix For: 4.2.0.Alpha2
>
>
> It has been discussed several times that the composite site is a kind of "weak point" in our build chain, because it allows cyclic dependencies, and it also introduces indirections that make it less straightforward to find out what a project should/does depend on to build.
> The benefit of composite now seem a bit light: it's cool because we can put it in parent pom and all builds succeed to get there dependencies, but out of that, there hasn't been much other use-cases. And as we want to provide more and more autonomy to project, this composite site they'd depend on is something that doesn't make them autonomous.
> So the idea is to move dependencies to project root poms. I've made a draft of how it would look like in project pom if we remove the "jbosstools-site" from parent pom and let projects manage their inter-dependencies: https://github.com/mickaelistria/jbosstools-javaee/tree/JBIDE-16309
> You can try this by running "mvn clean verify -P\!jbosstools-site". The "-P\!jbosstools-site" disable the jbosstools-site profile, which is the one controlling addition of the composite or ggregate to the resolver
> https://github.com/jbosstools/jbosstools-build/blob/master/parent/pom.xml...
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 3 months
[JBoss JIRA] (JBIDE-16280) VPE/XulRunner crashes workbench
by Mickael Istria (JIRA)
[ https://issues.jboss.org/browse/JBIDE-16280?page=com.atlassian.jira.plugi... ]
Mickael Istria commented on JBIDE-16280:
----------------------------------------
See suggested actions for VPE and BrowserSim:
* JBIDE-16314
* JBIDE-16315
[~kmarmaliykov]: what do you think about it? First step is to avoid the crash.
> VPE/XulRunner crashes workbench
> -------------------------------
>
> Key: JBIDE-16280
> URL: https://issues.jboss.org/browse/JBIDE-16280
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: xulrunner
> Affects Versions: 4.2.0.Alpha1
> Reporter: Mickael Istria
> Priority: Critical
> Fix For: 4.2.0.Alpha1
>
> Attachments: hs_err_pid20688.log
>
>
> After an install of JBDS 8.0.0.Alpha1 from installer (built locally with fixes from JBDS-2861), the application crashes a few seconds after startup.
> JVM creates me a thread dump, that you can find attached. Here is the header:
> {code}
> #
> # A fatal error has been detected by the Java Runtime Environment:
> #
> # SIGSEGV (0xb) at pc=0x00007fdea49f3255, pid=18578, tid=140596949411584
> #
> # JRE version: 7.0_25-b30
> # Java VM: OpenJDK 64-Bit Server VM (23.7-b01 mixed mode linux-amd64 compressed oops)
> # Problematic frame:
> # C [libxul.so+0xc81255] JSD_DebuggerOnForUser+0x978a2
> #
> {code}
> I'm running on Ubuntu 12.04.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 3 months
[JBoss JIRA] (JBIDE-16315) Start browsersin setting SWT_GTK3=0
by Mickael Istria (JIRA)
Mickael Istria created JBIDE-16315:
--------------------------------------
Summary: Start browsersin setting SWT_GTK3=0
Key: JBIDE-16315
URL: https://issues.jboss.org/browse/JBIDE-16315
Project: Tools (JBoss Tools)
Issue Type: Sub-task
Components: browsersim
Reporter: Mickael Istria
Fix For: 4.2.0.Alpha1
As BrowserSim is relying on xulrunner, and xulrunner is known to be crashing with GTK3, it would make sense to start the xulrunner process setting environment variable (or system property I'm not sure) SWT_GTK3=0
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 3 months
[JBoss JIRA] (JBIDE-16314) Avoid loading xulrunner on Linux
by Mickael Istria (JIRA)
Mickael Istria created JBIDE-16314:
--------------------------------------
Summary: Avoid loading xulrunner on Linux
Key: JBIDE-16314
URL: https://issues.jboss.org/browse/JBIDE-16314
Project: Tools (JBoss Tools)
Issue Type: Sub-task
Reporter: Mickael Istria
Fix For: 4.2.0.Alpha2
In order to avoid crash described in JBIDE-16280, we should avoid loading (or providing)the xulrunner binaries we ship on Windows until they are compatible with GTK3.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 3 months
[JBoss JIRA] (JBIDE-16286) CDI builder (not import, workspace rebuild) is very slow in wildfly
by Viacheslav Kabanovich (JIRA)
[ https://issues.jboss.org/browse/JBIDE-16286?page=com.atlassian.jira.plugi... ]
Viacheslav Kabanovich commented on JBIDE-16286:
-----------------------------------------------
[~adietish], is it possible that your computer is running other resource consuming applications so that it is low on memory and swap file is large? Also, please add more dumps that would statistically show where most time is spent.
> CDI builder (not import, workspace rebuild) is very slow in wildfly
> -------------------------------------------------------------------
>
> Key: JBIDE-16286
> URL: https://issues.jboss.org/browse/JBIDE-16286
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: cdi
> Affects Versions: 4.1.1.Final
> Reporter: Andre Dietisheim
> Assignee: Viacheslav Kabanovich
> Priority: Critical
> Labels: performance
> Fix For: 4.1.2.Final, 4.2.0.Alpha2
>
> Attachments: cdi-builder.ogv, cleanBuild.png, maven-preferences-hide-children.png, thread-dump-7_05.txt, thread-dump-7_19.txt, updatingPom.png, VisualVM 1.3.2 _083.png
>
>
> When working in a wildfly workspace with all wildfly projects imported and CDI builder enabled, workspace rebuilds (that you trigger by changing poms and then do maven update project) are a lot slower than without it. Re-building the whole workspace can easily take up to 20 minutes for me.
> Hard to give more general purpose details, I did a quick screencast to give an impression how slow things are for me.
> [^cdi-builder.ogv]
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 3 months
[JBoss JIRA] (JBIDE-16309) Move inter-JBT dependencies to component poms
by Denis Golovin (JIRA)
[ https://issues.jboss.org/browse/JBIDE-16309?page=com.atlassian.jira.plugi... ]
Denis Golovin commented on JBIDE-16309:
---------------------------------------
This sounds right. Should we open sub-tasks for every component? jbosstools-base has no dependencies so it is done already :)
> Move inter-JBT dependencies to component poms
> ---------------------------------------------
>
> Key: JBIDE-16309
> URL: https://issues.jboss.org/browse/JBIDE-16309
> Project: Tools (JBoss Tools)
> Issue Type: Enhancement
> Components: build
> Reporter: Mickael Istria
> Assignee: Mickael Istria
> Fix For: 4.2.0.Alpha2
>
>
> It has been discussed several times that the composite site is a kind of "weak point" in our build chain, because it allows cyclic dependencies, and it also introduces indirections that make it less straightforward to find out what a project should/does depend on to build.
> The benefit of composite now seem a bit light: it's cool because we can put it in parent pom and all builds succeed to get there dependencies, but out of that, there hasn't been much other use-cases. And as we want to provide more and more autonomy to project, this composite site they'd depend on is something that doesn't make them autonomous.
> So the idea is to move dependencies to project root poms. I've made a draft of how it would look like in project pom if we remove the "jbosstools-site" from parent pom and let projects manage their inter-dependencies: https://github.com/mickaelistria/jbosstools-javaee/tree/JBIDE-16309
> You can try this by running "mvn clean verify -P\!jbosstools-site". The "-P\!jbosstools-site" disable the jbosstools-site profile, which is the one controlling addition of the composite or ggregate to the resolver
> https://github.com/jbosstools/jbosstools-build/blob/master/parent/pom.xml...
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 3 months