[
https://issues.apache.org/jira/browse/OFBIZ-4773?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sharan Foga updated OFBIZ-4773:
---
Sprint: Bug Crush Event - 21/2/2015
Migrate to JACOCO for code coverage analysis
[
https://issues.apache.org/jira/browse/OFBIZ-4773?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Geisert updated OFBIZ-4773:
-
Component/s: framework
Migrate to JACOCO for code coverage analysis
://jira.codehaus.org/browse/SONAR-3536].
The ASF supports both ([SonarQube results are
there|https://analysis.apache.org/])
Anyway, after working some time on it, I'm also in favor of evaluating the
Jacoco possibility, see OFBIZ-4757
Migrate to JACOCO for code coverage analysis
on this:
https://bitbucket.org/jmhofer/cobertura4sbt/wiki/Home
But it appears to be proven otherwise. Nothing changes as fast as the people do.
Regards,
Pierre
Migrate to JACOCO for code coverage analysis
Key: OFBIZ-4773
Migrate to JACOCO for code coverage analysis
Key: OFBIZ-4773
URL: https://issues.apache.org/jira/browse/OFBIZ-4773
Project: OFBiz
Issue Type: Improvement
Reporter: Pierre Smits
[
https://issues.apache.org/jira/browse/OFBIZ-4773?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pierre Smits updated OFBIZ-4773:
Affects Version/s: SVN trunk
Migrate to JACOCO for code coverage analysis
ML: more audience (for those who filter)
Migrate to JACOCO for code coverage analysis
Key: OFBIZ-4773
URL: https://issues.apache.org/jira/browse/OFBIZ-4773
Project: OFBiz
Issue
Resolve base unit tests not executing and not contributing to code coverage
---
Key: OFBIZ-3662
URL: https://issues.apache.org/jira/browse/OFBIZ-3662
Project: OFBiz
and reopen a new one... Thanks to
Adrian's expanations
Resolve base unit tests not executing and not contributing to code coverage
---
Key: OFBIZ-3662
URL: https://issues.apache.org/jira/browse
and not contributing to code coverage
---
Key: OFBIZ-3662
URL: https://issues.apache.org/jira/browse/OFBIZ-3662
Project: OFBiz
Issue Type: Bug
Components: framework
https://issues.apache.org/jira/browse/OFBIZ-3659
Download cobertura code coverage jar so it can be used to compile and execute
tests with
Key: OFBIZ-3659
URL: https
on this issue to be integrated ?
Cheers,
Download cobertura code coverage jar so it can be used to compile and execute
tests with
Key: OFBIZ-3659
URL: https://issues.apache.org/jira
I don't suppose anyone has looked at EMMA (http://emma.sourceforge.net/) as an
alternative to Cobertura? It has a CPL license which means we could include
the jar.
Thanks
Scott
HotWax Media
http://www.hotwaxmedia.com
smime.p7s
Description: S/MIME cryptographic signature
I seem to recall that the issue may be that EMMA is not being actively
developed (that isn't to say people don't use it). As you probably
know I did some extensions to Adam's work with Cobertura so we could
be generating code coverage as part of the build and ultimately
publishing those
There was a thread in this list (with the same subject Code Coverage) between
Erwan and Adam: it seems like they discovered that Emma was a dead project...
Jacopo
On Apr 30, 2010, at 4:28 PM, Scott Gray wrote:
I don't suppose anyone has looked at EMMA (http://emma.sourceforge.net
, look at this thread :
http://ofbiz.135035.n4.nabble.com/Code-coverage-td1559131.html#a1559131
--
View this message in context:
http://ofbiz.135035.n4.nabble.com/Code-Coverage-tp2076993p2077028.html
Sent from the OFBiz - Dev mailing list archive at Nabble.com.
Scott Gray wrote:
I don't suppose anyone has looked at EMMA (http://emma.sourceforge.net/) as
an alternative to Cobertura? It has a CPL license which means we could
include the jar.
As already mentioned in this thread, and previously, the project was
last released in 2005. cobertura is
On 1/05/2010, at 3:49 AM, Adam Heath wrote:
Scott Gray wrote:
I don't suppose anyone has looked at EMMA (http://emma.sourceforge.net/) as
an alternative to Cobertura? It has a CPL license which means we could
include the jar.
As already mentioned in this thread, and previously, the
Resolve base unit tests not executing and not contributing to code coverage
---
Key: OFBIZ-3662
URL: https://issues.apache.org/jira/browse/OFBIZ-3662
Project: OFBiz
and not contributing to code coverage
---
Key: OFBIZ-3662
URL: https://issues.apache.org/jira/browse/OFBIZ-3662
Project: OFBiz
Issue Type: Bug
Components
dependency grab; but the compile
depends on it ... the only piece I see is it can be shutoff based on a a
sysclasspath. What am I missing?
Download cobertura code coverage jar so it can be used to compile and execute
tests
- mvn site:site. The normal
build does not include metrics. So, we could have something similar (hopefully
without Maven) that produces metrics outside a basic build.
Download cobertura code coverage jar so it can be used to compile and execute
tests
Download cobertura code coverage jar so it can be used to compile and execute
tests with
Key: OFBIZ-3659
URL: https://issues.apache.org/jira/browse/OFBIZ-3659
impact is that when they do a build it will pull
down this jar (if possible) and when they run the test container it will
instrument and generate code coverage metrics.
Download cobertura code coverage jar so it can be used to compile and execute
tests
download may not
constitute an optional dependency (since the user isn't really given an option).
Download cobertura code coverage jar so it can be used to compile and execute
tests
to create code coverage
metrics as part of the Ofbiz build process. Licensing restricts distribution
of cobertura with Ofbiz, so we have taken the approach to attempt to download
it before doing our build so it is available for any container that wants
instrumentation turned on (currently
process, not the build
process. Ideally, we should have a new ant target - reports or metrics -
that would include this and other code-quality reports.
Download cobertura code coverage jar so it can be used to compile and execute
tests
anything with that -- this is
the ability to compile with Cobertura so that when the test process executes it
can instrument and generate the code coverage metrics.
We can do some refactoring on the pluggable instrumentation implementation so
that it has a separate build process from the main
the download process such that our
automated ASF build will do the download (to ultimately get our frequent code
coverage metrics) but have it remain manual for developers / end-users? That
is really what I would want anyway (with no impact to developers / end-users).
Download cobertura code coverage
things. They download and execute a
number of reporting tools that aren't included in the final library. It's
pretty slick and extremely convenient.
Download cobertura code coverage jar so it can be used to compile and execute
tests
you're not going to
distribute it and if you don't know that the metrics library is there then how
would you know to exclude it?
Example: Someone may decide to distribute a precompiled version of OFBiz for
the convenience of the community.
Download cobertura code coverage jar so it can
in sequence, currently I think it
does:
svn co ...
ant run-install
ant run-tests
ant docs-all
then some other stuff for the nightly builds
Download cobertura code coverage jar so it can be used to compile and execute
tests
that downloads and executes a
third-party library, then the user will be aware of it. We can even include
that bit of information in the ant task's description.
Compiling OFBiz != Downloading and executing code metrics.
Download cobertura code coverage jar so it can be used to compile
so I guess we're talking about
different things. In the patch Compiling OFBiz == Downloading code metrics
tools.
Download cobertura code coverage jar so it can be used to compile and execute
tests
cobertura code coverage jar so it can be used to compile and execute
tests with
Key: OFBIZ-3659
URL: https://issues.apache.org/jira/browse/OFBIZ-3659
Project: OFBiz
step though and not automated.
The new targets created in the patch look good to me, I just don't want them
called from any processing targets.
Download cobertura code coverage jar so it can be used to compile and execute
tests
.
Download cobertura code coverage jar so it can be used to compile and execute
tests with
Key: OFBIZ-3659
URL: https://issues.apache.org/jira/browse/OFBIZ-3659
[
https://issues.apache.org/jira/browse/OFBIZ-3659?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bob Morley updated OFBIZ-3659:
--
Attachment: (was: OFBIZ-3659_AutomateDownloadOfCobertura.patch)
Download cobertura code coverage
(the last one I manually modified and
messed it up).
Download cobertura code coverage jar so it can be used to compile and execute
tests with
Key: OFBIZ-3659
URL: https
at IO because it had an old Cobertura
report generated from 2008; but it appears they no longer generate code
coverage that way. Commons Lang has code coverage but they use Bamboo/Clover.
The one build file that had download-dependency target (it was for junit) was
very nice, but all it really
target.
- executing the ant cobertura-report target will create a very nice set of
html reports
Here is my question -- when looking at the reports it showed 100% line code
coverage in UtilValidate (for example) but this was for 111 lines. Clearly
this class has many more lines than that, and when I
everything with the ant run-tests target.
- executing the ant cobertura-report target will create a very nice set of
html reports
Here is my question -- when looking at the reports it showed 100% line code
coverage in UtilValidate (for example) but this was for 111 lines. Clearly
this class has many
On Apr 6, 2010, at 1:50 PM, Adam Heath wrote:
Bob Morley wrote:
Here is my question -- when looking at the reports it showed 100%
line code
coverage in UtilValidate (for example) but this was for 111 lines.
Clearly
this class has many more lines than that, and when I opened it up I
Robert Morley wrote:
Also, we were talking in the office -- our understanding is that the
Cobertura license would restrict Ofbiz from redistribution, but it
should be able to use it as part of their build process. Do you think
there would be an issue include a target that downloads and
On 6/04/2010, at 11:59 AM, Robert Morley wrote:
On Apr 6, 2010, at 1:50 PM, Adam Heath wrote:
Bob Morley wrote:
Here is my question -- when looking at the reports it showed 100% line code
coverage in UtilValidate (for example) but this was for 111 lines. Clearly
this class has many
Scott Gray wrote:
On 6/04/2010, at 11:59 AM, Robert Morley wrote:
On Apr 6, 2010, at 1:50 PM, Adam Heath wrote:
Bob Morley wrote:
Here is my question -- when looking at the reports it showed 100% line code
coverage in UtilValidate (for example) but this was for 111 lines. Clearly
Hi all,
while taking a new look to code coverage, will it be hard to use emma
instead of cobertura ?
In this case, we could include the library to OFBiz, as it is under a
CPL license.
Cheers,
--
Erwan de FERRIERES
www.nereide.biz
Erwan de FERRIERES wrote:
Hi all,
while taking a new look to code coverage, will it be hard to use emma
instead of cobertura ?
In this case, we could include the library to OFBiz, as it is under a
CPL license.
Not super hard, no; I wrote the interface to be extensible with other
tools.
Adam Heath wrote:
Erwan de FERRIERES wrote:
Hi all,
while taking a new look to code coverage, will it be hard to use emma
instead of cobertura ?
In this case, we could include the library to OFBiz, as it is under a
CPL license.
Not super hard, no; I wrote the interface to be extensible
Adam Heath wrote:
Adam Heath wrote:
Erwan de FERRIERES wrote:
Hi all,
while taking a new look to code coverage, will it be hard to use emma
instead of cobertura ?
In this case, we could include the library to OFBiz, as it is under a
CPL license.
Not super hard, no; I wrote the interface
On 17/02/2010 20:53, Adam Heath wrote:
../..
Actually, emma doesn't look like it's maintained anymore. Last
download available was made back in 2005.
It's why I saw too...
--
Erwan de FERRIERES
www.nereide.biz
Huge tasks are prone to failure, what we really have is a lot of
little tasks ahead. If you're writing some code, think about writing
the tests that should code along with it. Hopefully it'll become so
common place that anyone who doesn't do it will just look silly.
Regards
Scott
HotWax
Sure Scott,
Good recommendation, I will remember...
BTW, we could already open an umbrella issue in Jira and add subtask as things
go on?
I can't see a better way to coordinate this work
Jacques
From: Scott Gray scott.g...@hotwaxmedia.com
Huge tasks are prone to failure, what we really have
We could but I don't think it would help us track progress very well,
there are just too many tests that need to be created. A good start
IMO would be to go through every open bug and create a test case that
reproduces the problem and attach them as patches to be committed with
the fix.
Hi Jacques,
inline
Le 11/12/2009 08:47, Jacques Le Roux a écrit :
What about groovy scripts, are they handled by Cobertura?
From what I know Cobertura needs .class files, and for the groovy
files, it would mean to compile them first
http://docs.codehaus.org/display/GROOVY/Code+Coverage
On 11/12/2009, at 11:02 PM, Erwan de FERRIERES wrote:
But if we just stay on the services, this vould give a great
overview of their coverage.
As we are in a SOA system, and service is the most important part of
the system, we have to be sure they are tested.
The easiest way to achieve
, it
would mean to compile them first
http://docs.codehaus.org/display/GROOVY/Code+Coverage+with+Cobertura
Class are created when they are used and placed in cache. As suggested Scott we could use the wonderful artifact info mechanism to
deal with this aspect and also the others (not UI
Jacques Le Roux wrote:
What about groovy scripts, are they handled by Cobertura?
And actions in Screens, is it worth do something? I guess checking
static structural files like web.xml, ofbiz-component.xml files (and
all xml like them, controllers, menus, commonsScreens and such) is not
/display/GROOVY/Code+Coverage+with+Cobertura
No, it needs a byte array that contains class data. I haven't looked
inside groovy internals in a bit, but I'm fairly certain that at some
point it creates said byte array, seeing as how the jvm requires it to
do so.
The coverage stuff I have done for ofbiz is based on the method I did
it for webslinger. I wrote a shim to allow for other coverage tools
to be used, then wrote a classpath/jar walker to find all classes
matching a particular pattern, a dynamic temporary classloader to load
the instrumenter, then
Adam Heath wrote:
The coverage stuff I have done for ofbiz is based on the method I did
it for webslinger. I wrote a shim to allow for other coverage tools
to be used, then wrote a classpath/jar walker to find all classes
matching a particular pattern, a dynamic temporary classloader to load
Hi Adam and Scott,
From what we see, it seems that only the junit tests are executed.
Cobertura or any other code-coverage tool does not know how to test /use
simple methods, and are only testing java code.
From what I know, it is the same for all coverage tools, so it would be
necessary
I am working on unit tests for the framework/base component. I hope to
have them committed soon.
Thanks for the info!
-Adrian
Adam Heath wrote:
I've thrown some things together this week, to implement code coverage
anaylsis for ofbiz. The code itself is not tied to any particular
code
Scott Gray wrote:
Hi Adam,
Looking at the results my first impression is that the coverage is
under-reported. For example, the accounting component has quite a few
tests but no coverage is shown at all (except for the test package
itself). Possibly because there is lot of logic in simple
On 11/12/2009, at 6:41 AM, Adam Heath wrote:
Scott Gray wrote:
Hi Adam,
Looking at the results my first impression is that the coverage is
under-reported. For example, the accounting component has quite a
few
tests but no coverage is shown at all (except for the test package
itself).
From: Scott Gray scott.g...@hotwaxmedia.com
On 11/12/2009, at 6:41 AM, Adam Heath wrote:
Scott Gray wrote:
Hi Adam,
Looking at the results my first impression is that the coverage is
under-reported. For example, the accounting component has quite a
few
tests but no coverage is shown at
Scott Gray wrote:
On 11/12/2009, at 6:41 AM, Adam Heath wrote:
Scott Gray wrote:
Hi Adam,
Looking at the results my first impression is that the coverage is
under-reported. For example, the accounting component has quite a few
tests but no coverage is shown at all (except for the test
Adam Heath wrote:
Scott Gray wrote:
On 11/12/2009, at 6:41 AM, Adam Heath wrote:
Scott Gray wrote:
Hi Adam,
Looking at the results my first impression is that the coverage is
under-reported. For example, the accounting component has quite a few
tests but no coverage is shown at all (except
Adrian Crum wrote:
Adam Heath wrote:
Scott Gray wrote:
On 11/12/2009, at 6:41 AM, Adam Heath wrote:
Scott Gray wrote:
Hi Adam,
Looking at the results my first impression is that the coverage is
under-reported. For example, the accounting component has quite a few
tests but no coverage
Adam Heath wrote:
Adrian Crum wrote:
Adam Heath wrote:
Scott Gray wrote:
On 11/12/2009, at 6:41 AM, Adam Heath wrote:
Scott Gray wrote:
Hi Adam,
Looking at the results my first impression is that the coverage is
under-reported. For example, the accounting component has quite a few
tests
On 11/12/2009, at 11:55 AM, Adam Heath wrote:
Scott Gray wrote:
On 11/12/2009, at 6:41 AM, Adam Heath wrote:
Scott Gray wrote:
Hi Adam,
Looking at the results my first impression is that the coverage is
under-reported. For example, the accounting component has quite
a few
tests but no
Adrian Crum wrote:
http://www.brainfood.com/ofbiz-coverage/
I like the holiday-themed colors. It would be cool if incomplete
coverage could be displayed as partially eaten sugar cookies.
That's standard cobertura scheme.
Scott Gray wrote:
Note that framework/base has almost 100% coverage. But that's a bad
thing, because it's not explicitly testing it; all that code just
happens to be utilized during the rest of the test run.
Of course explicitly testing framework/base would be much better but why
is the
On 11/12/2009, at 12:34 PM, Adam Heath wrote:
Scott Gray wrote:
Note that framework/base has almost 100% coverage. But that's a bad
thing, because it's not explicitly testing it; all that code just
happens to be utilized during the rest of the test run.
Of course explicitly testing
Scott Gray wrote:
Additionally, just because a line has been noted in cobertura, doesn't
mean all variations have been tested. Consider the case that some
condition is doing some kind of pattern match, or looking at
Collection.contains or Map.containsKey. It's much simpler to verify
that
Now the point would be to show the coverage of the simple methods and
also, maybe in sometime, the selenium coverage.
What would be great is finding a way to indicate which services are
tested, and then display it in the webtools. This won't give an
information as precise as cobertura but
What about groovy scripts, are they handled by Cobertura?
And actions in Screens, is it worth do something? I guess checking static structural files like web.xml, ofbiz-component.xml files
(and all xml like them, controllers, menus, commonsScreens and such) is not necessary?
Jacques
From:
From: Adam Heath doo...@brainfood.com
Additionally, the way the classloaders are constructed is a bit odd.
The bootstrap loader only has ofbiz.jar. The code then creates a
classloader will *all* jars in base/lib, recursively. After the
containers and components are started, yet another
A huge task ahead...
Jacques
From: Adam Heath doo...@brainfood.com
Scott Gray wrote:
Additionally, just because a line has been noted in cobertura, doesn't
mean all variations have been tested. Consider the case that some
condition is doing some kind of pattern match, or looking at
I've thrown some things together this week, to implement code coverage
anaylsis for ofbiz. The code itself is not tied to any particular
code coverage tool(there's a plugin system for it). Currently I have
one written for cobertura, but that's gpl, so not compatible with apache.
The first run I
some things together this week, to implement code coverage
anaylsis for ofbiz. The code itself is not tied to any particular
code coverage tool(there's a plugin system for it). Currently I have
one written for cobertura, but that's gpl, so not compatible with apache.
The first run I just
this week, to implement code coverage
anaylsis for ofbiz. The code itself is not tied to any particular
code coverage tool(there's a plugin system for it). Currently I have
one written for cobertura, but that's gpl, so not compatible with
apache.
The first run I just finished had some test failures
I'm not clear on what you're asking. I use code analysis here, but it's
not something I would consider including in the project. Why would the
tool's license be an issue?
-Adrian
Adam Heath wrote:
I'm looking at various code coverage tools; there are very few free ones
available.
I've
license be an issue?
-Adrian
Adam Heath wrote:
I'm looking at various code coverage tools; there are very few free
ones
available.
I've personally used cobertura; it's gpl v2.0(1), so not compatible.
clover is what is installed for use by apache projects; but it's
actually non-free, so I'm
I'm looking at various code coverage tools; there are very few free ones
available.
I've personally used cobertura; it's gpl v2.0(1), so not compatible.
clover is what is installed for use by apache projects; but it's
actually non-free, so I'm not even going to consider it.
emma is cpl 1.0(2
I plan on integrating cobertura(1)(a code-coverage tool) into ofbiz.
This is so we can see what code is actually used during a test run.
I'll do this by pre-compiling all build/lib/*.jar into
build/cobertura/*.jar, then, during the test run, I'll load the
cobertura jars first. An extension
86 matches
Mail list logo
