On May 12, 2013, at 8:01, sebb <seb...@gmail.com> wrote:
> On 11 May 2013 14:45, Gary Gregory <garydgreg...@gmail.com> wrote:
>> 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 understand.
>
> But my point is that if problems are discovered in a release of CP
> it's very easy to fix them.
> Suppose CP29 causes problems for NET. We work out the solution, and
> release CP30.
> Meanwhile NET has to stick with CP28, possibly adding temporary
> changes to its pom.
> Once CP30 is released (which could be a quickly as 4 days), NET can
> update to CP30.
> Other components can stick with CP29 or upgrade to CP30 as necessary.
>
> The point is that CP is easy and quick to release.
> Also broken versions can just be avoided.
Ok, that makes sense.
Gary
>
>> 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
>
> ---------------------------------------------------------------------
> 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
