Mr Connolly, what's the status with report-only mojo<http://jira.codehaus.org/browse/MCOBERTURA-86>, will there be a release of the cobertura maven plugin anytime soon, and what are the chances of having this mojo included in the next release?
Here <http://jira.codehaus.org/browse/MCOBERTURA-94> is another solid reason to make a new cobertura plugin release. Not sure tho what's the policy regarding Java version in maven plugins, new Cobertura 1.9.1 seems to require Java 1.5. Regards, Stevo. 2009/4/29 Stephen Connolly <[email protected]> > +1000 on report-only > > > 2009/4/29 Stevo Slavić <[email protected]> > >> I agree it's a hack. Anyway, aggregate/merge support is one issue, what >> about all the others. Any thoughts on report-only mojo? Btw, surefire report >> plug-in has one too. >> >> >> Regards, >> Stevo. >> >> 2009/4/29 Stephen Connolly <[email protected]> >> >>> Hackedy-hackedy-hack! >>> >>> Maven 3.x with the build plan stuff will fix all these issues... and >>> change the baby's nappy while it's at it >>> >>> ;-) >>> >>> >>> -Stephen >>> >>> 2009/4/29 Stevo Slavić <[email protected]> >>> >>>> Parent project could create initial empty cobertura.ser file, children >>>> modules could merge their coverage data into it. Question is how to get >>>> parent (aggregator module) to have report generated at the end of the whole >>>> build. >>>> >>>> If such scenario is not naturally supported in Maven2, maybe a >>>> workaround would be to have plugin when executing report mojo for parent >>>> project actually just register a JVM shutdown hook (similarly to Cobertura) >>>> and generate report when Maven build successfully ends (if build fails, >>>> coverage report doesn't mean much anyway). This assumes that report >>>> generation will not fail, and if it does it won't fail a build (IMO just >>>> warning/error log feedback will suffice). Also, it assumes that plugin >>>> will, >>>> before registering shutdown hook, obtain and save reference for later to >>>> all >>>> necessary info needed for report generation so that generation doesn't fail >>>> because build has ended. >>>> >>>> >>>> Regards, >>>> Stevo. >>>> >>>> >>>> 2009/4/29 Stephen Connolly <[email protected]> >>>> >>>>> >>>>> >>>>> 2009/4/29 Stevo Slavić <[email protected]> >>>>> >>>>>> I've asked because there seems to be a number of more or less >>>>>> important issues, very small number of issues has been resolved in >>>>>> last >>>>>> year<http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&mode=hide&pid=11226&status=5&status=6&updated:previous=-52w&sorter/field=updated&sorter/order=DESC>, >>>>>> even tho at least some of the issues have high vote count and/or have >>>>>> patches from the community, like this >>>>>> one<http://jira.codehaus.org/browse/MCOBERTURA-86>I'm currently most >>>>>> interested in where I'm proposing a new >>>>>> cobertura:report-only mojo to be added - currentl one can generate report >>>>>> only through cobertura:cobertura mojo which executes test phase in >>>>>> cobertura >>>>>> lifecycle so tests in integration-test phase do not get run; with >>>>>> cobertura:report-only mojo user has responsibility to instrument code and >>>>>> execute tests in whichever phase (s)he chooses. >>>>>> >>>>>> About aggregating coverage results in a multimodule project, isn't it >>>>>> enough to >>>>>> >>>>>> - resolve this <http://jira.codehaus.org/browse/MCOBERTURA-33>very >>>>>> long standing issue, by implementing support for cobertura:merge mojo & >>>>>> task; >>>>>> - have users configure cobertura:instrument mojo at parent and >>>>>> thus inherited by every child; >>>>>> - implement some new cobertura:aggregate report mojo which would >>>>>> (like report-only mojo bind to validate phase and) just call merge >>>>>> task >>>>>> before generating report for a parent project only? >>>>>> >>>>>> >>>>> You think this is the solution... but whe you try to roll a release, in >>>>> the release:perform stage, either the aggregator parent module runs first, >>>>> and there's no results to include, or it runs last (in which case it >>>>> cannot >>>>> be the parent and you have to put the config all over the place)... >>>>> >>>>> the clover solution is to fork the build... but that just makes matters >>>>> worse with everyone forking the build and a forked build only removing the >>>>> forking plugin from the lifecycle and not removing any previous plugins >>>>> that >>>>> forked the build... >>>>> >>>>> end result is that if you have N modules, you run the unit tests approx >>>>> 2*N*(N-1) times at least... more if you have another plugin that forks the >>>>> build... more still if you have a depth > 1 >>>>> >>>>> -Stephen >>>>> >>>>> >>>>>> - >>>>>> >>>>>> >>>>>> Regards, >>>>>> Stevo. >>>>>> >>>>>> 2009/4/29 Stephen Connolly <[email protected]> >>>>>> >>>>>>> My understanding is that there is an issue with aggregating coverage >>>>>>> results for a multi-module project and forking the build... >>>>>>> >>>>>>> >>>>>>> Clover faces the same issue but is farther down the road, and it >>>>>>> looks like there is no good solution for Maven 2.x (i.e. need the build >>>>>>> plan >>>>>>> stuff from 3.x) >>>>>>> >>>>>>> The Cobertura plugin seems to work fine otherwise, why would it need >>>>>>> a new release? >>>>>>> >>>>>>> -Stephen >>>>>>> >>>>>>> 2009/4/29 Stevo Slavić <[email protected]> >>>>>>> >>>>>>> Hello Codehaus Mojo Users, >>>>>>>> >>>>>>>> Are there any active Cobertura Maven Plug-in developers? Project >>>>>>>> appears to be dead... >>>>>>>> >>>>>>>> Regards, >>>>>>>> Stevo. >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> >
