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