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