On Sat, May 11, 2013 at 9:02 AM, sebb <seb...@gmail.com> wrote: > On 11 May 2013 13:25, Gary Gregory <garydgreg...@gmail.com> wrote: > > On Fri, May 10, 2013 at 3:51 PM, Luc Maisonobe <luc.maison...@free.fr > >wrote: > > > >> Hi Sebb, > >> > >> Le 09/05/2013 20:03, sebb a écrit : > >> > On 9 May 2013 18:28, Luc Maisonobe <l...@spaceroots.org> wrote: > >> >> Hi all, > >> >> > >> >> Le 08/05/2013 22:46, Luc Maisonobe a écrit : > >> >>> > >> >>> > >> >>> > >> >>> Gary Gregory <garydgreg...@gmail.com> a écrit : > >> >>> > >> >>>> On Wed, May 8, 2013 at 4:32 PM, Gary Gregory < > garydgreg...@gmail.com> > >> >>>> wrote: > >> >>>> > >> >>>>> In the Maven output I see: > >> >>>>> > >> >>>>> [INFO] Skipping JaCoCo execution due to missing execution data > file > >> >>>>> > >> >>>> > >> >>>> Which I from running "mvn clean site". > >> >> > >> >> I found the problem. > >> >> What happened is that in [io] you override the command line arguments > >> >> while running tests in the maven-surefire-plugin. JaCoCo also > overrides > >> >> them to add an agent that will observe tests runs. > >> >> > >> >> In order to be able to merge both settings (the [io] settings which > >> >> change the max memory using option -Xmx and the complex JaCoCo > setting), > >> >> then you need to change in [io] pom.xml the maven-surefire-plugin > >> >> configuration from: > >> >> > >> >> <configuration> > >> >> <forkMode>pertest</forkMode> > >> >> <!-- limit memory size see IO-161 --> > >> >> <argLine>-Xmx25M</argLine> > >> >> ... > >> >> </configuration> > >> >> > >> >> to: > >> >> > >> >> <configuration> > >> >> <forkMode>pertest</forkMode> > >> >> <!-- limit memory size see IO-161 --> > >> >> <!-- the ${argLine} preserves jacoco agent settings (see > >> >> https://github.com/jacoco/eclemma/issues/22) --> > >> >> <argLine>-Xmx25M ${argLine}</argLine> > >> >> ... > >> >> </configuration> > >> >> > >> >> I have added some documentation about this in both the release notes > and > >> >> the pom itself. > >> >> > >> >> > >> >> Another implication of the switch to JaCoCo is that tests must be run > >> >> using Java 1.5 at least (of course, this does not imply the component > >> >> code must be Java 5, only, it can still target an older version). Is > >> >> this a problem? > >> > > >> > That is a problem. > >> > For components that target 1.4 or earlier it is vital that they can be > >> > compiled/tested using the relevant Java version, as well as using more > >> > recent JVMs. > >> > > >> > Running with earlier JVMs is achieved by using a profile, so maybe > >> > unsuitable profiles can be detected and used to disable JaCoCo for > >> > that run. > >> > >> I have updated the profile so it is now automatically enabled when the > >> JDK version is at least 1.5. > >> > >> IS there anything else I should do before starting a release candidate > >> for commoms-parent 29? > >> > > > > IMO, you should at least test this new scheme with at least one other > > Commons component. > > +1 > > > Since it looks like this may break some component that currently use > > Cobertura and not produce a coverage report unless the POM for that > project > > is edited -- like in [io] for example, I suggest that you at least notify > > the list of which projects will break and consider updating said projects > > to match the new scheme you are putting in place. "You broke it, you > bought > > it" ;) > > However it is not the case that releasing a new CP will break any > components. > It is up to each component whether they update or not. >
That's true in principle but in practice, components must update at some point, like for the recent SCM Pub/Sub requirement. Well, OK, you could do it all in your own POM, but you get my point. ;) Gary > > If there are other useful changes in CP, I suppose it might be worth > releasing two new versions of CP. > - one with all other updates > - another with the coverage changes > > It only takes 3 days with lazy consensus to release - and it's a > relatively simple process. > > > Gary > > > > > >> > >> Luc > >> > >> > > >> > So the site build would need to be done using Java 1.5+, but > >> > individual builds/tests (and potentially CI builds) could still use > >> > older JVMs. > >> > > >> >> I think several other plugin also need Java 5, but I > >> >> don't know for sure. > >> > > >> > In general Maven needs Java 1.5+, but the compile/test phases can > >> > still currently be done using an earlier JVM by using the profile > >> > mechanism. > >> > > >> >> Luc > >> >> > >> >>> > >> >>> Perhaps should you try "mvn clean test site"? > >> >>> > >> >>> I did not run clean before running site, so I may have kept some > files > >> you miss? > >> >>> > >> >>> Luc > >> >>> > >> >>>> > >> >>>> Gary > >> >>>> > >> >>>> > >> >>>>> > >> >>>>> Gary > >> >>>>> > >> >>>>> > >> >>>>> On Wed, May 8, 2013 at 4:18 PM, Luc Maisonobe <l...@spaceroots.org > > > >> >>>> wrote: > >> >>>>> > >> >>>>>> > >> >>>>>> > >> >>>>>> > >> >>>>>> Gary Gregory <garydgreg...@gmail.com> a écrit : > >> >>>>>> > >> >>>>>>> On Wed, May 8, 2013 at 3:58 PM, Luc Maisonobe > >> >>>> <luc.maison...@free.fr> > >> >>>>>>> wrote: > >> >>>>>>> > >> >>>>>>>> Le 08/05/2013 21:11, Gary Gregory a écrit : > >> >>>>>>>>> I updated my local commons-io to 29-SNAPSHOT and I do not see > a > >> >>>>>>> coverage > >> >>>>>>>>> report. > >> >>>>>>>>> > >> >>>>>>>>> How is that fixed? > >> >>>>>>>> > >> >>>>>>>> Well, I did not have to do anything for [math]. Did you install > >> >>>> the > >> >>>>>>>> snapshot locally with "mvn install"? > >> >>>>>>> > >> >>>>>>> > >> >>>>>>> Yep. > >> >>>>>>> > >> >>>>>>> > >> >>>>>>>> Don't you have the skipReports > >> >>>>>>>> property set to true? > >> >>>>>>>> > >> >>>>>>> > >> >>>>>>> > >> >>>>>>> Well, I do not think so, all of the other reports were generated > >> >>>> with > >> >>>>>>> the > >> >>>>>>> site. > >> >>>>>> > >> >>>>>> This property triggers a profile which was used only to skip > >> >>>> cobertura. > >> >>>>>> So I have left this in place, > >> >>>>>> which means this property does act on jacoco now, and only on > jacoco > >> >>>> (I'm > >> >>>>>> not sure it is still useful). > >> >>>>>> > >> >>>>>> Luc > >> >>>>>> > >> >>>>>>> > >> >>>>>>> I suggest you try a couple of Commons project before pushing > >> >>>> version 29 > >> >>>>>>> of > >> >>>>>>> the parent POM. > >> >>>>>>> > >> >>>>>>> Gary > >> >>>>>>> > >> >>>>>>> > >> >>>>>>>> Luc > >> >>>>>>>> > >> >>>>>>>>> > >> >>>>>>>>> Gary > >> >>>>>>>>> > >> >>>>>>>>> > >> >>>>>>>>> On Fri, Apr 5, 2013 at 7:44 AM, luc <l...@spaceroots.org> > wrote: > >> >>>>>>>>> > >> >>>>>>>>>> Le 2013-04-05 00:10, Gary Gregory a écrit : > >> >>>>>>>>>> > >> >>>>>>>>>>> On Thu, Apr 4, 2013 at 4:03 PM, sebb <seb...@gmail.com> > >> >>>> wrote: > >> >>>>>>>>>>> > >> >>>>>>>>>>> CP 28 moved Cobertura to a profile called "reporting". > >> >>>>>>>>>>>> > >> >>>>>>>>>>>> The profile was activated by default, but could be disabled > >> >>>> by > >> >>>>>>> using > >> >>>>>>>>>>>> > >> >>>>>>>>>>>> -DskipReports=true > >> >>>>>>>>>>>> or > >> >>>>>>>>>>>> -P!reporting > >> >>>>>>>>>>>> > >> >>>>>>>>>>>> IIRC, the idea was to move expensive (long-running) reports > >> >>>> to a > >> >>>>>>>> profile > >> >>>>>>>>>>>> that could be disabled if necessary. > >> >>>>>>>>>>>> > >> >>>>>>>>>>>> However Cobertura causes problems with some projects, and > >> >>>> the > >> >>>>>>> project > >> >>>>>>>>>>>> seems > >> >>>>>>>>>>>> to be unmaintained, so perhaps it would be sensible to > >> >>>> disable > >> >>>>>>>> Cobertura > >> >>>>>>>>>>>> by > >> >>>>>>>>>>>> default. > >> >>>>>>>>>>>> In which case the profile and property should be renamed to > >> >>>>>>> reflect > >> >>>>>>>> the > >> >>>>>>>>>>>> fact that it only affects Cobertura. > >> >>>>>>>>>>>> > >> >>>>>>>>>>>> Possibly even drop Cobertura entirely from the parent POM. > >> >>>>>>>>>>>> > >> >>>>>>>>>>>> However, I think it is important that some code coverage > >> >>>> tool is > >> >>>>>>> used. > >> >>>>>>>>>>>> > >> >>>>>>>>>>>> > >> >>>>>>>>>>> OK, but which one? I know some projects use Clover but I'd > >> >>>> rather > >> >>>>>>> we > >> >>>>>>>> use > >> >>>>>>>>>>> another FOSS tool. I know Jacoco has been mentioned.. maybe > >> >>>>>>> [math] > >> >>>>>>>> wants > >> >>>>>>>>>>> to > >> >>>>>>>>>>> be the guinea pig? > >> >>>>>>>>>>> > >> >>>>>>>>>> > >> >>>>>>>>>> Yes ! > >> >>>>>>>>>> > >> >>>>>>>>>> I already use Jacoco elsewhere and am very happy with it. It > >> >>>> is > >> >>>>>>> also > >> >>>>>>>> used > >> >>>>>>>>>> in our > >> >>>>>>>>>> Sonar instance if I remember correctly. > >> >>>>>>>>>> > >> >>>>>>>>>> The only point I had to adjust in the other project was to > set > >> >>>> up > >> >>>>>>>> manually > >> >>>>>>>>>> an entry in > >> >>>>>>>>>> the site menu to point to the generated html pages, as jacoco > >> >>>> was > >> >>>>>>> not > >> >>>>>>>>>> fully integrated > >> >>>>>>>>>> in the regular reports produced by maven. Is there a complete > >> >>>>>>>> integration > >> >>>>>>>>>> available now? > >> >>>>>>>>>> > >> >>>>>>>>>> Luc > >> >>>>>>>>>> > >> >>>>>>>>>> > >> >>>>>>>>>>> Gary > >> >>>>>>>>>>> > >> >>>>>>>>>> > >> >>>>>>>>>> > >> >>>>>>>>>> > >> >>>>>>>> > >> >>>>>> > >> >>>>> > >> > ------------------------------**------------------------------**--------- > >> >>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.**apache.org > < > >> >>>>>>>> dev-unsubscr...@commons.apache.org> > >> >>>>>>>>>> For additional commands, e-mail: dev-h...@commons.apache.org > >> >>>>>>>>>> > >> >>>>>>>>>> > >> >>>>>>>>> > >> >>>>>>>>> > >> >>>>>>>> > >> >>>>>>>> > >> >>>>>>>> > >> >>>> > --------------------------------------------------------------------- > >> >>>>>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > >> >>>>>>>> For additional commands, e-mail: dev-h...@commons.apache.org > >> >>>>>>>> > >> >>>>>>>> > >> >>>>>> > >> >>>>>> -- > >> >>>>>> Envoyé de mon téléphone Android avec K-9 Mail. Excusez la > brièveté. > >> >>>>>> > >> >>>>>> > >> >>>> > --------------------------------------------------------------------- > >> >>>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > >> >>>>>> For additional commands, e-mail: dev-h...@commons.apache.org > >> >>>>>> > >> >>>>>> > >> >>>>> > >> >>>>> > >> >>>>> -- > >> >>>>> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org > >> >>>>> Java Persistence with Hibernate, Second > >> >>>> Edition<http://www.manning.com/bauer3/> > >> >>>>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/ > > > >> >>>>> Spring Batch in Action <http://www.manning.com/templier/> > >> >>>>> Blog: http://garygregory.wordpress.com > >> >>>>> Home: http://garygregory.com/ > >> >>>>> Tweet! http://twitter.com/GaryGregory > >> >>>>> > >> >>> > >> >> > >> >> > >> >> --------------------------------------------------------------------- > >> >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > >> >> For additional commands, e-mail: dev-h...@commons.apache.org > >> >> > >> > > >> > --------------------------------------------------------------------- > >> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > >> > For additional commands, e-mail: dev-h...@commons.apache.org > >> > > >> > > >> > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > >> For additional commands, e-mail: dev-h...@commons.apache.org > >> > >> > > > > > > -- > > E-Mail: garydgreg...@gmail.com | ggreg...@apache.org > > Java Persistence with Hibernate, Second Edition< > http://www.manning.com/bauer3/> > > JUnit in Action, Second Edition <http://www.manning.com/tahchiev/> > > Spring Batch in Action <http://www.manning.com/templier/> > > Blog: http://garygregory.wordpress.com > > Home: http://garygregory.com/ > > Tweet! http://twitter.com/GaryGregory > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org Java Persistence with Hibernate, Second Edition<http://www.manning.com/bauer3/> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/> Spring Batch in Action <http://www.manning.com/templier/> Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory