[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 use word link in meaning some relation to class/jar file. Thanks for explanation.
I agree with you Sonar is probably using classes/jars from target folder. He is using pom.xml file so I guess it analyses it and then uses class/jar files dependent on information stored in pom.xml file. But I was not able to find information confirming it. But this part of jenkins job log file is suggesting that I could be right about it:
{noformat}
[INFO] [07:30:47.133] Base dir: /home/jbossqa/workspace/jbosstools-trunk.jsf.bot.tests.codecoverage/modules/jsf/plugins
[INFO] [07:30:47.133] Working dir: /home/jbossqa/workspace/jbosstools-trunk.jsf.bot.tests.codecoverage/modules/jsf/plugins/target/sonar
[INFO] [07:30:47.133] Binary dirs: /home/jbossqa/workspace/jbosstools-trunk.jsf.bot.tests.codecoverage/modules/jsf/plugins/target/classes
{noformat}
> 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, 5 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:
----------------------------------------
{quote}I think it's not problem of Sonar. jacoco.exec file is generated without links to class/jar files because they are installed from update site not from local file system.{quote}
Actually, the jacoco.exec file doesn't contain "linked" to filesystem. It contains the "ID" of classes is uses, and the issue is that it runs against pack200'd classes (from repo) and tries to report against non-pack200'd classes (from Maven build). The ID of the class is modified by pack200 so Jacoco reports can't understand the relationship between a pack200'd class and an plain one.
{quote}ame classpath as maven build{quote}
What's more interesting is the classpath of surefire tests. You can find it in <test>/target/work/configuration/config.ini, it's the osgi.bundles property. It's 100% sure that Sonar does NOT read it. I don't really know where it looks for class instead. I'd bet in the target/ folder of other 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, 5 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 think it's not problem of Sonar. jacoco.exec file is generated without links to class/jar files because they are installed from update site not from local file system. Probably because of pack200 once it was disabled everything works in past. But it's just my guess.
Sonar is not using jar files from target directory or is not able to link them with data in jacoco.exec. Those files are available and when build is forced to use locally built artfacts Sonar analyze is correct. I don't think Sonar can use the same classpath as maven build uses as far as I can say tycho is building classpath for integration tests and I don't think Sonar has functionality to build the same path as tycho do
> 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, 5 months
[JBoss JIRA] (JBIDE-15932) CordovaSim needs to display console logs
by Konstantin Marmalyukov (JIRA)
[ https://issues.jboss.org/browse/JBIDE-15932?page=com.atlassian.jira.plugi... ]
Konstantin Marmalyukov commented on JBIDE-15932:
------------------------------------------------
{Konstatin/Ilya - can we have firebug lite display the console ?
Can we avoid the autoclosing - or at least have it reopen on reload ?}
Firebug lite displays console logs. But it cannot display console.log from deviceready event because deviceready event comes before firebug lite loads. Firebug lite is just a javascript, so looks like it cannot handle js errors.
Maybe we can implement reopening of firebug for refresh like it is done for weinre. But even if we can do I think firebug will not load before deviceready event will happen.
Implementing logging into eclipse console is rather hard and it is feature request.
> CordovaSim needs to display console logs
> ----------------------------------------
>
> Key: JBIDE-15932
> URL: https://issues.jboss.org/browse/JBIDE-15932
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: browsersim
> Affects Versions: 4.1.1.Beta1
> Reporter: Gorkem Ercan
> Assignee: Konstantin Marmalyukov
> Priority: Blocker
> Labels: jbds711
> Fix For: 4.1.2.Final, 4.2.0.Alpha2
>
>
> When a cordova application is launched the console.log calls are not displayed on Eclipse console (or anywhere else). CordovaSim needs a place to display the logs either within eclipse or on the Ripple console
--
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, 5 months
[JBoss JIRA] (JBDS-2734) Forge 2 in JBDS
by Lincoln Baxter III (JIRA)
[ https://issues.jboss.org/browse/JBDS-2734?page=com.atlassian.jira.plugin.... ]
Lincoln Baxter III commented on JBDS-2734:
------------------------------------------
Most components of JBDS will continue to support Java 6. Forge will not run unless you have Java 7.
Forge 1 will be disabled by default, but will be installable on demand. Forge 2 will be active by default. (That is how I understand it.)
> Forge 2 in JBDS
> ---------------
>
> Key: JBDS-2734
> URL: https://issues.jboss.org/browse/JBDS-2734
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: forge, requirements
> Reporter: Burr Sutter
> Assignee: Koen Aers
>
> Is Forge 2 ready to be included in JBDS ?
--
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, 5 months
[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. - *Done*
- Disable switcher for Linux platform - *Done*
# 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. - *Done*
- Disable switcher for Linux platform - *Done*
# 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 - *Done*
# 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. - *Done*
> - Disable switcher for Linux platform - *Done*
> # 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, 5 months