Le 11/05/2013 15:45, Gary Gregory a écrit :
> 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. ;)
Yes, I get your point. So I will do the following points in order:
1) looking at a few components to see if the change breaks something
2) in case of problems, find how to change the components pom
3) notify the list about what I have found
4) release parent pom with the current status
(i.e. with only jacoco and surefire updated)
5) update the component pom with problems
6) help others if I missed some components problems
Luc
>
> 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
>>
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
