You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by fe...@apache.org on 2011/10/18 15:52:43 UTC
svn commit: r1185659 - /james/project/trunk/pom.xml
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.
Modified:
james/project/trunk/pom.xml
Modified: james/project/trunk/pom.xml
URL: http://svn.apache.org/viewvc/james/project/trunk/pom.xml?rev=1185659&r1=1185658&r2=1185659&view=diff
==============================================================================
--- james/project/trunk/pom.xml (original)
+++ james/project/trunk/pom.xml Tue Oct 18 13:52:43 2011
@@ -702,11 +702,6 @@
</plugin>
<plugin>
<groupId>org.codehaus.mojo</groupId>
- <artifactId>emma-maven-plugin</artifactId>
- <version>1.0-alpha-3</version>
- </plugin>
- <plugin>
- <groupId>org.codehaus.mojo</groupId>
<artifactId>exec-maven-plugin</artifactId>
<version>1.2</version>
</plugin>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: svn commit: r1185659 - /james/project/trunk/pom.xml
Posted by Stefano Bagnara <ap...@bago.org>.
2011/10/20 Felix Knecht <fe...@apache.org>:
> On 10/18/2011 04:42 PM, Stefano Bagnara wrote:
>>
>> 2011/10/18<fe...@apache.org>:
>>>
>>> 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: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: EMMA plugin (was svn commit: r1185659 - /james/project/trunk/pom.xml)
Posted by Felix Knecht <fe...@otego.com>.
Implemented a) in the SNAPSHOT version. Thanks for hints an investigations.
Regards
Felix
On 11/17/2011 05:01 PM, Stefano Bagnara wrote:
> 2011/11/17 Norman Maurer<no...@googlemail.com>:
>> I think a) is the way to go then. I dont think we need to take special care
>> here about the license...
>
> I just read this:
> http://www.apache.org/legal/resolved.html#cobertura
>
> So I'm fine with a) , too.
>
> Stefano
>
>> thanks,
>> norman
>>
>> Am Donnerstag, 17. November 2011 schrieb Felix Knecht<fe...@otego.com>:
>>> 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/server-dev@james.apache.org/msg36812.html
>>>
>>>
>>> On 10/20/2011 12:42 PM, Stefano Bagnara wrote:
>>>> 2011/10/20 Felix Knecht<fe...@apache.org>:
>>>>> On 10/18/2011 04:42 PM, Stefano Bagnara wrote:
>>>>>>
>>>>>> 2011/10/18<fe...@apache.org>:
>>>>>>>
>>>>>>> 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: server-dev-unsubscribe@james.apache.org
>>>> For additional commands, e-mail: server-dev-help@james.apache.org
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>>> For additional commands, e-mail: server-dev-help@james.apache.org
>>>
>>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: EMMA plugin (was svn commit: r1185659 - /james/project/trunk/pom.xml)
Posted by Stefano Bagnara <ap...@bago.org>.
2011/11/17 Norman Maurer <no...@googlemail.com>:
> I think a) is the way to go then. I dont think we need to take special care
> here about the license...
I just read this:
http://www.apache.org/legal/resolved.html#cobertura
So I'm fine with a) , too.
Stefano
> thanks,
> norman
>
> Am Donnerstag, 17. November 2011 schrieb Felix Knecht <fe...@otego.com>:
>> 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/server-dev@james.apache.org/msg36812.html
>>
>>
>> On 10/20/2011 12:42 PM, Stefano Bagnara wrote:
>>> 2011/10/20 Felix Knecht<fe...@apache.org>:
>>>> On 10/18/2011 04:42 PM, Stefano Bagnara wrote:
>>>>>
>>>>> 2011/10/18<fe...@apache.org>:
>>>>>>
>>>>>> 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: server-dev-unsubscribe@james.apache.org
>>> For additional commands, e-mail: server-dev-help@james.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>> For additional commands, e-mail: server-dev-help@james.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: EMMA plugin (was svn commit: r1185659 - /james/project/trunk/pom.xml)
Posted by Norman Maurer <no...@googlemail.com>.
I think a) is the way to go then. I dont think we need to take special care
here about the license...
thanks,
norman
Am Donnerstag, 17. November 2011 schrieb Felix Knecht <fe...@otego.com>:
> 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/server-dev@james.apache.org/msg36812.html
>
>
> On 10/20/2011 12:42 PM, Stefano Bagnara wrote:
>> 2011/10/20 Felix Knecht<fe...@apache.org>:
>>> On 10/18/2011 04:42 PM, Stefano Bagnara wrote:
>>>>
>>>> 2011/10/18<fe...@apache.org>:
>>>>>
>>>>> 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: server-dev-unsubscribe@james.apache.org
>> For additional commands, e-mail: server-dev-help@james.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
>
EMMA plugin (was svn commit: r1185659 - /james/project/trunk/pom.xml)
Posted by Felix Knecht <fe...@otego.com>.
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/server-dev@james.apache.org/msg36812.html
On 10/20/2011 12:42 PM, Stefano Bagnara wrote:
> 2011/10/20 Felix Knecht<fe...@apache.org>:
>> On 10/18/2011 04:42 PM, Stefano Bagnara wrote:
>>>
>>> 2011/10/18<fe...@apache.org>:
>>>>
>>>> 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: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: svn commit: r1185659 - /james/project/trunk/pom.xml
Posted by Felix Knecht <fe...@apache.org>.
On 10/18/2011 04:42 PM, Stefano Bagnara wrote:
> 2011/10/18<fe...@apache.org>:
>> 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
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?
>> Modified:
>> james/project/trunk/pom.xml
>>
>> Modified: james/project/trunk/pom.xml
>> URL: http://svn.apache.org/viewvc/james/project/trunk/pom.xml?rev=1185659&r1=1185658&r2=1185659&view=diff
>> ==============================================================================
>> --- james/project/trunk/pom.xml (original)
>> +++ james/project/trunk/pom.xml Tue Oct 18 13:52:43 2011
>> @@ -702,11 +702,6 @@
>> </plugin>
>> <plugin>
>> <groupId>org.codehaus.mojo</groupId>
>> -<artifactId>emma-maven-plugin</artifactId>
>> -<version>1.0-alpha-3</version>
>> -</plugin>
>> -<plugin>
>> -<groupId>org.codehaus.mojo</groupId>
>> <artifactId>exec-maven-plugin</artifactId>
>> <version>1.2</version>
>> </plugin>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>> For additional commands, e-mail: server-dev-help@james.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: svn commit: r1185659 - /james/project/trunk/pom.xml
Posted by Stefano Bagnara <ap...@bago.org>.
2011/10/18 <fe...@apache.org>:
> 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).
> Modified:
> james/project/trunk/pom.xml
>
> Modified: james/project/trunk/pom.xml
> URL: http://svn.apache.org/viewvc/james/project/trunk/pom.xml?rev=1185659&r1=1185658&r2=1185659&view=diff
> ==============================================================================
> --- james/project/trunk/pom.xml (original)
> +++ james/project/trunk/pom.xml Tue Oct 18 13:52:43 2011
> @@ -702,11 +702,6 @@
> </plugin>
> <plugin>
> <groupId>org.codehaus.mojo</groupId>
> - <artifactId>emma-maven-plugin</artifactId>
> - <version>1.0-alpha-3</version>
> - </plugin>
> - <plugin>
> - <groupId>org.codehaus.mojo</groupId>
> <artifactId>exec-maven-plugin</artifactId>
> <version>1.2</version>
> </plugin>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org