[JBoss JIRA] (JBIDE-15640) BrowserSim: use JavaFX WebView as a browser engine
by Ilya Buziuk (JIRA)
[ https://issues.jboss.org/browse/JBIDE-15640?page=com.atlassian.jira.plugi... ]
Ilya Buziuk updated JBIDE-15640:
--------------------------------
Description:
JavaFX [WebView|http://docs.oracle.com/javafx/2/api/javafx/scene/web/WebView.html] supports Debugger API and could be embedded into BrowserSim as an alternative to the SWT Browser.
*Pros:*
# WebView supports Debugger API - we can enable full featured [DevTools|https://developers.google.com/chrome-developer-tools/] and/or integrate it with [EclipseDebugger|https://code.google.com/p/chromedevtools/wiki/EclipseDebu...]
# It is available on all OSes where Oracle JVM 7 is installed - no requirement to install Safari and 32-bit JVM on Windows
# Can be used together with the SWT Browser (i.e. if there is no JavaFX present, we can fallback to the SWT Browser in runtime)
*Cons:*
# Not a part of OpenJDK, Oracle JVM 7 only (not sure if JavaFX could be installed standalone)
# window.localStorage is not supported (may be a problem for CordovaSim)
# Character encoding problems on some installations
# Debugger API bindings to Java are not final now - we can face Java run-time errors with later versions of Oracle JVMs
*On the high level our plan is to:*
# Implement possibility of switching BrowserSim's web engine SWT.WEBKIT / JavaFx WebView. This possibility will be enabled only for windows and mac os users. Due to native errors coupled with gtk3 usage (related jira https://javafx-jira.kenai.com/browse/RT-35264 ) there will be only one web engine on Linux - SWT.WEBKIT. - *Coding in progress*
# Solve perfomance issues. Debugger freezes rather often - *Coding in progress*
# Mock javaFX dependencies - *Done*
# Fix LiveReload and Touch Events for JavaFx WebView - *Done*
# Move Dev tools front-end source code to the separate plugin / git submodule - *Coding in progress*
# Port for debugging should not be hardcoded
was:
JavaFX [WebView|http://docs.oracle.com/javafx/2/api/javafx/scene/web/WebView.html] supports Debugger API and could be embedded into BrowserSim as an alternative to the SWT Browser.
*Pros:*
# WebView supports Debugger API - we can enable full featured [DevTools|https://developers.google.com/chrome-developer-tools/] and/or integrate it with [EclipseDebugger|https://code.google.com/p/chromedevtools/wiki/EclipseDebu...]
# It is available on all OSes where Oracle JVM 7 is installed - no requirement to install Safari and 32-bit JVM on Windows
# Can be used together with the SWT Browser (i.e. if there is no JavaFX present, we can fallback to the SWT Browser in runtime)
*Cons:*
# Not a part of OpenJDK, Oracle JVM 7 only (not sure if JavaFX could be installed standalone)
# window.localStorage is not supported (may be a problem for CordovaSim)
# Character encoding problems on some installations
# Debugger API bindings to Java are not final now - we can face Java run-time errors with later versions of Oracle JVMs
*On the high level our plan is to:*
# Implement possibility of switching BrowserSim's web engine SWT.WEBKIT / JavaFx WebView. This possibility will be enabled only for windows and mac os users. Due to native errors coupled with gtk3 usage (related jira https://javafx-jira.kenai.com/browse/RT-35264 ) there will be only one web engine on Linux - SWT.WEBKIT. - *Coding in progress*
# Solve perfomance issues. Debugger freezes rather often - *Coding in progress*
# Mock javaFX dependencies - *Done*
# Fix LiveReload and Touch Events for JavaFx WebView - *Done*
# Move Dev tools front-end source code to the separate plugin / git submodule
# Port for debugging should not be hardcoded
> BrowserSim: use JavaFX WebView as a browser engine
> --------------------------------------------------
>
> Key: JBIDE-15640
> URL: https://issues.jboss.org/browse/JBIDE-15640
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: browsersim
> Reporter: Yahor Radtsevich
> Assignee: Ilya Buziuk
> Fix For: 4.2.x
>
>
> JavaFX [WebView|http://docs.oracle.com/javafx/2/api/javafx/scene/web/WebView.html] supports Debugger API and could be embedded into BrowserSim as an alternative to the SWT Browser.
> *Pros:*
> # WebView supports Debugger API - we can enable full featured [DevTools|https://developers.google.com/chrome-developer-tools/] and/or integrate it with [EclipseDebugger|https://code.google.com/p/chromedevtools/wiki/EclipseDebu...]
> # It is available on all OSes where Oracle JVM 7 is installed - no requirement to install Safari and 32-bit JVM on Windows
> # Can be used together with the SWT Browser (i.e. if there is no JavaFX present, we can fallback to the SWT Browser in runtime)
> *Cons:*
> # Not a part of OpenJDK, Oracle JVM 7 only (not sure if JavaFX could be installed standalone)
> # window.localStorage is not supported (may be a problem for CordovaSim)
> # Character encoding problems on some installations
> # Debugger API bindings to Java are not final now - we can face Java run-time errors with later versions of Oracle JVMs
> *On the high level our plan is to:*
> # Implement possibility of switching BrowserSim's web engine SWT.WEBKIT / JavaFx WebView. This possibility will be enabled only for windows and mac os users. Due to native errors coupled with gtk3 usage (related jira https://javafx-jira.kenai.com/browse/RT-35264 ) there will be only one web engine on Linux - SWT.WEBKIT. - *Coding in progress*
> # Solve perfomance issues. Debugger freezes rather often - *Coding in progress*
> # Mock javaFX dependencies - *Done*
> # Fix LiveReload and Touch Events for JavaFx WebView - *Done*
> # Move Dev tools front-end source code to the separate plugin / git submodule - *Coding in progress*
> # Port for debugging should not be hardcoded
--
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, 2 months
[JBoss JIRA] (JBIDE-16214) Code Coverage jobs needs to have locally available measured plugins
by Vlado Pakan (JIRA)
[ https://issues.jboss.org/browse/JBIDE-16214?page=com.atlassian.jira.plugi... ]
Vlado Pakan commented on JBIDE-16214:
-------------------------------------
These are parameters of Sonar Jenkins plugin we use:
{noformat}
-Dsonar.jacoco.reportPath=${WORKSPACE}/target/jacoco.exec -Dsonar.dynamicAnalysis=reuseReports -Dsonar.surefire.reportsPath=${WORKSPACE}/tests/org.jboss.tools.jsf.ui.bot.test/target/surefire-reports
{noformat}
We are reusing surefire reports and it was working fine before maven build starts to use JBT plugins from update site not the ones built locally
> Code Coverage jobs needs to have locally available measured plugins
> -------------------------------------------------------------------
>
> Key: JBIDE-16214
> URL: https://issues.jboss.org/browse/JBIDE-16214
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: build
> Affects Versions: 4.1.1.CR1
> Reporter: Vlado Pakan
> Assignee: Mickael Istria
> Fix For: 4.1.x
>
>
> Code Coverage calculating via maven build returns 0% coverage because it's using source code and binary plugins installed from update site.
> When these are built locally prior to build calculating code coverage it returns correct results.
> Unfortunately sometimes maven build used plugins installed from update site instead of those which are locally build.
> We need to find way how to fix this.
> It's already reported here https://bugs.eclipse.org/bugs/show_bug.cgi?id=352560
--
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, 2 months
[JBoss JIRA] (JBIDE-16214) Code Coverage jobs needs to have locally available measured plugins
by Mickael Istria (JIRA)
[ https://issues.jboss.org/browse/JBIDE-16214?page=com.atlassian.jira.plugi... ]
Mickael Istria commented on JBIDE-16214:
----------------------------------------
AFAIK, Sonar doesn't use report files, it directly use the jacoco.exec file and generate reports on his side.
I don't know which mechanism Sonar uses to generate reports. The ideal one would be that it takes jars from classpath, and sources from modules.
> Code Coverage jobs needs to have locally available measured plugins
> -------------------------------------------------------------------
>
> Key: JBIDE-16214
> URL: https://issues.jboss.org/browse/JBIDE-16214
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: build
> Affects Versions: 4.1.1.CR1
> Reporter: Vlado Pakan
> Assignee: Mickael Istria
> Fix For: 4.1.x
>
>
> Code Coverage calculating via maven build returns 0% coverage because it's using source code and binary plugins installed from update site.
> When these are built locally prior to build calculating code coverage it returns correct results.
> Unfortunately sometimes maven build used plugins installed from update site instead of those which are locally build.
> We need to find way how to fix this.
> It's already reported here https://bugs.eclipse.org/bugs/show_bug.cgi?id=352560
--
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, 2 months
[JBoss JIRA] (JBIDE-16214) Code Coverage jobs needs to have locally available measured plugins
by Vlado Pakan (JIRA)
[ https://issues.jboss.org/browse/JBIDE-16214?page=com.atlassian.jira.plugi... ]
Vlado Pakan edited comment on JBIDE-16214 at 1/14/14 6:07 AM:
--------------------------------------------------------------
I'm sorry for confusing you Sonar results were correct before when maven build was able to use local source/binary files.
I misunderstood your question. I meant Jenkins Sonar Plugins is properly picking jacoco analyzes and reports files and properly publishing them to sonar server but because jacoco files are generated without proper source/binary files published code coverage is 0%
So issue is not fixed
was (Author: vpakan):
I'm sorry for confusing Sonar results were correct before when maven build was able to use local source/binary files.
I misunderstood your question. I meant Jenkins Sonar Plugins is properly picking jacoco analyzes and reports files and properly publishing them to sonar server but because jacoco files are generated without proper source/binary files published code coverage is 0%
So issue is not fixed
> Code Coverage jobs needs to have locally available measured plugins
> -------------------------------------------------------------------
>
> Key: JBIDE-16214
> URL: https://issues.jboss.org/browse/JBIDE-16214
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: build
> Affects Versions: 4.1.1.CR1
> Reporter: Vlado Pakan
> Assignee: Mickael Istria
> Fix For: 4.1.x
>
>
> Code Coverage calculating via maven build returns 0% coverage because it's using source code and binary plugins installed from update site.
> When these are built locally prior to build calculating code coverage it returns correct results.
> Unfortunately sometimes maven build used plugins installed from update site instead of those which are locally build.
> We need to find way how to fix this.
> It's already reported here https://bugs.eclipse.org/bugs/show_bug.cgi?id=352560
--
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, 2 months
[JBoss JIRA] (JBIDE-16214) Code Coverage jobs needs to have locally available measured plugins
by Vlado Pakan (JIRA)
[ https://issues.jboss.org/browse/JBIDE-16214?page=com.atlassian.jira.plugi... ]
Vlado Pakan commented on JBIDE-16214:
-------------------------------------
I'm sorry for confusing Sonar results were correct before when maven build was able to use local source/binary files.
I misunderstood your question. I meant Jenkins Sonar Plugins is properly picking jacoco analyzes and reports files and properly publishing them to sonar server but because jacoco files are generated without proper source/binary files published code coverage is 0%
So issue is not fixed
> Code Coverage jobs needs to have locally available measured plugins
> -------------------------------------------------------------------
>
> Key: JBIDE-16214
> URL: https://issues.jboss.org/browse/JBIDE-16214
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: build
> Affects Versions: 4.1.1.CR1
> Reporter: Vlado Pakan
> Assignee: Mickael Istria
> Fix For: 4.1.x
>
>
> Code Coverage calculating via maven build returns 0% coverage because it's using source code and binary plugins installed from update site.
> When these are built locally prior to build calculating code coverage it returns correct results.
> Unfortunately sometimes maven build used plugins installed from update site instead of those which are locally build.
> We need to find way how to fix this.
> It's already reported here https://bugs.eclipse.org/bugs/show_bug.cgi?id=352560
--
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, 2 months
[JBoss JIRA] (JBIDE-16214) Code Coverage jobs needs to have locally available measured plugins
by Mickael Istria (JIRA)
[ https://issues.jboss.org/browse/JBIDE-16214?page=com.atlassian.jira.plugi... ]
Mickael Istria commented on JBIDE-16214:
----------------------------------------
> Results published to Sonar seams to be correct.
Cool. I guess Sonar uses the test project classpath + module sources to generate report. It's actually the most universal approach.
It's also what I've more or less done in the script (with a bit less success).
So do you think this ticket can be closed?
> Code Coverage jobs needs to have locally available measured plugins
> -------------------------------------------------------------------
>
> Key: JBIDE-16214
> URL: https://issues.jboss.org/browse/JBIDE-16214
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: build
> Affects Versions: 4.1.1.CR1
> Reporter: Vlado Pakan
> Assignee: Mickael Istria
> Fix For: 4.1.x
>
>
> Code Coverage calculating via maven build returns 0% coverage because it's using source code and binary plugins installed from update site.
> When these are built locally prior to build calculating code coverage it returns correct results.
> Unfortunately sometimes maven build used plugins installed from update site instead of those which are locally build.
> We need to find way how to fix this.
> It's already reported here https://bugs.eclipse.org/bugs/show_bug.cgi?id=352560
--
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, 2 months
[JBoss JIRA] (JBIDE-16214) Code Coverage jobs needs to have locally available measured plugins
by Vlado Pakan (JIRA)
[ https://issues.jboss.org/browse/JBIDE-16214?page=com.atlassian.jira.plugi... ]
Vlado Pakan commented on JBIDE-16214:
-------------------------------------
Jenkins plugin is not so important we can use also script to generate code coverage reports but for sure we need to have code coverage published to Sonar.
Results published to Sonar seams to be correct.
I think you should not waste your time to tweak your script regarding to multiple class issue. It has to be fixed in JBT and I don't think that you will find a way how to fix it in code coverage generation script. This is coming from code coverage analyze done by some class from jacocoant.jar so I guess it's not under developer control unless there is some property which allow you to ignore this exception IMHO.
> Code Coverage jobs needs to have locally available measured plugins
> -------------------------------------------------------------------
>
> Key: JBIDE-16214
> URL: https://issues.jboss.org/browse/JBIDE-16214
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: build
> Affects Versions: 4.1.1.CR1
> Reporter: Vlado Pakan
> Assignee: Mickael Istria
> Fix For: 4.1.x
>
>
> Code Coverage calculating via maven build returns 0% coverage because it's using source code and binary plugins installed from update site.
> When these are built locally prior to build calculating code coverage it returns correct results.
> Unfortunately sometimes maven build used plugins installed from update site instead of those which are locally build.
> We need to find way how to fix this.
> It's already reported here https://bugs.eclipse.org/bugs/show_bug.cgi?id=352560
--
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, 2 months
[JBoss JIRA] (JBIDE-16214) Code Coverage jobs needs to have locally available measured plugins
by Mickael Istria (JIRA)
[ https://issues.jboss.org/browse/JBIDE-16214?page=com.atlassian.jira.plugi... ]
Mickael Istria commented on JBIDE-16214:
----------------------------------------
> Yes we use jacoco jenkins plugin for code coverage
Ok. I don't know how to have it working for the Jenkins plugin. The script I've written dynamically computes the list of jars to use by reading surefire configuration. This cannot be achieved by the Jenkins plugin, it would require to rewrite another Jenkins plugin.
On the Jenkins instance, we have an extra build step running the (currently Ant-based) script that generates HTML report, and we use the Jenkins Link plugin to add a link to the reports.
> Yes we publish code coverage results to sonar. It's requested by management
Ok, That's cool. How are Sonar reports behaving? Do they reports accurate metrics? Not sure it will be able to bind classes, and I don't know what we can do with it.
A general solution could be that Tycho avoids using the pack200 jars. http://dev.eclipse.org/mhonarc/lists/tycho-user/msg05194.html However, I couldn't get much help on this topic.
About the multiple class issue, I'll try to reproduce the scenario you describe and find whether there's something that can be done in the script. But IMO, the solution is more to fix jars to avoid multiple class definition than tweaking the script to workaround this bad practice.
> Code Coverage jobs needs to have locally available measured plugins
> -------------------------------------------------------------------
>
> Key: JBIDE-16214
> URL: https://issues.jboss.org/browse/JBIDE-16214
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: build
> Affects Versions: 4.1.1.CR1
> Reporter: Vlado Pakan
> Assignee: Mickael Istria
> Fix For: 4.1.x
>
>
> Code Coverage calculating via maven build returns 0% coverage because it's using source code and binary plugins installed from update site.
> When these are built locally prior to build calculating code coverage it returns correct results.
> Unfortunately sometimes maven build used plugins installed from update site instead of those which are locally build.
> We need to find way how to fix this.
> It's already reported here https://bugs.eclipse.org/bugs/show_bug.cgi?id=352560
--
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, 2 months
[JBoss JIRA] (JBIDE-16214) Code Coverage jobs needs to have locally available measured plugins
by Vlado Pakan (JIRA)
[ https://issues.jboss.org/browse/JBIDE-16214?page=com.atlassian.jira.plugi... ]
Vlado Pakan commented on JBIDE-16214:
-------------------------------------
Yes we use jacoco jenkins plugin for code coverage
Yes we publish code coverage results to sonar. It's requested by management
Steps I have done:
0. Compile all tests from <jbosstools-integrations-tests>/tests/
{noformat}
mvn clean install
{noformat}
1. Run maven build command from <jbosstools-integrations-tests>/tests/org.jboss,tools.jsf.ui.bot.tests
{noformat}
mvn clean verify -Dswtbot.test.skip=false
{noformat}
2. Run groovy script from <jbosstools-integrations-tests>
{noformat}
groovy -cp ~/jacocogroovy/jacocoant.jar:~/jacocogroovy/ant.jar ~/jacocogroovy/jacoco.groovy org.jboss
{noformat}
Getting mentioned exception
3. Run groovy script from <jbosstools-integrations-tests>
{noformat}
groovy -cp ~/jacocogroovy/jacocoant.jar:~/jacocogroovy/ant.jar ~/jacocogroovy/jacoco.groovy org.jboss.tools
{noformat}
No exception
> Code Coverage jobs needs to have locally available measured plugins
> -------------------------------------------------------------------
>
> Key: JBIDE-16214
> URL: https://issues.jboss.org/browse/JBIDE-16214
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: build
> Affects Versions: 4.1.1.CR1
> Reporter: Vlado Pakan
> Assignee: Mickael Istria
> Fix For: 4.1.x
>
>
> Code Coverage calculating via maven build returns 0% coverage because it's using source code and binary plugins installed from update site.
> When these are built locally prior to build calculating code coverage it returns correct results.
> Unfortunately sometimes maven build used plugins installed from update site instead of those which are locally build.
> We need to find way how to fix this.
> It's already reported here https://bugs.eclipse.org/bugs/show_bug.cgi?id=352560
--
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, 2 months