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.
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
