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<fel...@apache.org>: >>> On 10/18/2011 04:42 PM, Stefano Bagnara wrote: >>>> >>>> 2011/10/18<fel...@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-unsubscr...@james.apache.org >> For additional commands, e-mail: server-dev-h...@james.apache.org >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org > For additional commands, e-mail: server-dev-h...@james.apache.org > >
