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
