thanks,
norman
Am Donnerstag, 17. November 2011 schrieb Felix Knecht<[email protected]>:
After all it looks like there are comming up some unexpected problems
using the EMMA plugin instead if the cobertura plugin:
- Multi module projects are not really supported (or it's simply too old
or not really maven 3.x compatible). When running specific goals in a
submodule for the maven-jar-plugin e.g. the instrumentation goal must be
run in the submodule again and it must be executed after the additional
jar-plugin goals. There are more of the same problems -> that's not a
clean, clear way to go
- Report generation seems to be also problematical when it comes to
multi-module projects. Because of the mentioned above the report generation
may fail and the error says "instrumentation has already been done" - looks
like a chicken-egg problem
- The described problems above to not only have impacts on the module
itself, but also for projects using a the jar of such a module as
dependency (see also Normans mail [1] - thanks for bringing up this
problem).
Sorry about being too enhousiastic putting the EMMA-plugin into the
lately released TLP pom.xml :-/
IMO we should
a) either use the cobertura plugin as it is only used for report
generation and code review (I'm not aware that it's needed in any James
project to build a distribution)
b) do code review without knowing about test code coverage
c) find another suitable plugin for this (what I haven't up to now)
and finally a), b) or c) will need to find the way into the next (soon)
release of the TLP pom.xml
WDOT?
Thanks and regards
Felix
[1] http://www.mail-archive.com/[email protected]/msg36812.html
On 10/20/2011 12:42 PM, Stefano Bagnara wrote:
2011/10/20 Felix Knecht<[email protected]>:
On 10/18/2011 04:42 PM, Stefano Bagnara wrote:
2011/10/18<[email protected]>:
Author: felixk
Date: Tue Oct 18 13:52:43 2011
New Revision: 1185659
URL: http://svn.apache.org/viewvc?rev=1185659&view=rev
Log:
Both (emma / cobertura) plugins are for measure of codecoverage of
tests.
Using only one of the plugins should fullfill the needs. If I've
chosen for
any reasons the wrong one please let me know. For now I left cobertura
plugin.
AFAIK cobertura is GPL while emma is CPL. As long as we don't bundle
them and don't require them to build our products we should be fine
with both, but I guess that if in doubt we should better choose emma
as CPL is a category B license
(http://www.apache.org/legal/3party.html).
I thought the cobertura plugin to be of Apache license:
http://mojo.codehaus.org/cobertura-maven-plugin/license.html
The plugin is Apache Licensed but the cobertura jar is GPL
It is also correctly reported in the dependency report:
http://mojo.codehaus.org/cobertura-maven-plugin/dependencies.html
But the right place to look for the license is here:
http://cobertura.sourceforge.net/license.html
"The Cobertura ant tasks are licensed under the Apache Software
License, Version 1.1. The rest of Cobertura is licensed under the GNU
General Public License, Version 2.0. See below for detailed
explanations."
And as you can see the cobertura license page has a long explanation
and concludes with an "it all depends on how you interpret the
license".
AFAICS it's only used to generate reports and it's not required to
build the
product itself but for code review.
I can find other Apache projects using this plugin also - but this
doesn't
means that it's the way to go for us and I'm not an expert in such
things.
Can anybody say more about this?
What does cobertura gives us more than emma? If there is no reason to
use cobertura instead of emma why don't we simply keep emma (you
commit message sounds like you randomly chose one) so we don't waste
time trying to give answers to the complex licensing stuff? (I believe
we are safe to produce reports with a GPL product, but I'm not a
lawyer, and I like emma)
If, instead, we have good reasons to prefer cobertura then it makes
sense to ask Robert (he's the most experienced in our team, wrt
licensing) and maybe file an issue to ASF "LEGAL" jira project.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
