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]
