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.

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

Reply via email to