You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by sebb <se...@gmail.com> on 2013/04/04 22:03:31 UTC
[ALL] Cobertura and Parent POM
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.
Re: [ALL] Cobertura and Parent POM
Posted by Luc Maisonobe <Lu...@free.fr>.
Le 08/05/2013 21:58, Luc Maisonobe a écrit :
> 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"? Don't you have the skipReports
> property set to true?
Another point: did you try a complete "mvn site"? I don't understand
much in maven internals, but it seems to not generate reports the same
way when you pinpoint a plugin goal and when you generate everything.
For the record, the maven version I use is:
(lehrin) luc% mvn --version
Apache Maven 3.0.4
Maven home: /usr/share/maven
Java version: 1.6.0_27, vendor: Sun Microsystems Inc.
Java home: /usr/lib/jvm/java-6-openjdk-amd64/jre
Default locale: fr_FR, platform encoding: UTF-8
OS name: "linux", version: "3.2.0-4-amd64", arch: "amd64", family: "unix"
(lehrin) luc%
Also did you see the donwloading of jacoco plugin during the maven run?
Luc
>
> Luc
>
>>
>> Gary
>>
>>
>> On Fri, Apr 5, 2013 at 7:44 AM, luc <lu...@spaceroots.org> wrote:
>>
>>> Le 2013-04-05 00:10, Gary Gregory a écrit :
>>>
>>>> On Thu, Apr 4, 2013 at 4:03 PM, sebb <se...@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<de...@commons.apache.org>
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [ALL] Cobertura and Parent POM
Posted by sebb <se...@gmail.com>.
On 12 May 2013 21:56, Luc Maisonobe <lu...@spaceroots.org> wrote:
> Le 11/05/2013 23:25, Luc Maisonobe a écrit :
>> Le 11/05/2013 15:45, Gary Gregory a écrit :
>>> On Sat, May 11, 2013 at 9:02 AM, sebb <se...@gmail.com> wrote:
>>>
>>>> On 11 May 2013 13:25, Gary Gregory <ga...@gmail.com> wrote:
>>>>> On Fri, May 10, 2013 at 3:51 PM, Luc Maisonobe <Luc.Maisonobe@free.fr
>>>>> wrote:
>>>>>
>>>>>> Hi Sebb,
>>>>>>
>>>>>> Le 09/05/2013 20:03, sebb a écrit :
>>>>>>> On 9 May 2013 18:28, Luc Maisonobe <lu...@spaceroots.org> wrote:
>>>>>>>> Hi all,
>>>>>>>>
>>>>>>>> Le 08/05/2013 22:46, Luc Maisonobe a écrit :
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Gary Gregory <ga...@gmail.com> a écrit :
>>>>>>>>>
>>>>>>>>>> On Wed, May 8, 2013 at 4:32 PM, Gary Gregory <
>>>> garydgregory@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
>
> I have done this for almost all proper components (bcel beanutils
> betwixt bsf chain cli codec collections compress configuration csv
> daemon dbcp dbutils digester discovery el email exec fileupload functor
> imaging io jci jcs jexl jxpath lang launcher logging math modeler net
> ognl pool primitives proxy scxml validator vfs).
>
>> 2) in case of problems, find how to change the components pom
>
> The needed changes were:
>
> [beanutils], [imaging], [io], [jcs], [ognl] : add the ${argLine}
> variable in the <argLine> configuration for surefire.
>
> This change may also been added to [configuration] and [lang], but in
> fact the change is in a commented out part of the pom.
>
> A specific change for [logging] is due to the fact it completely
> disables test coverage, so we need to disable jacoco instead of
> disabling cobertura. The change is therefore to replace
>
> <groupId>org.codehaus.mojo</groupId>
> <artifactId>cobertura-maven-plugin</artifactId>
> <version>${commons.cobertura.version}</version>
> <configuration>
> <skip>true</skip>
> </configuration>
>
> with
>
> <groupId>org.jacoco</groupId>
> <artifactId>jacoco-maven-plugin</artifactId>
> <version>${commons.jacoco.version}</version>
> <configuration>
> <skip>true</skip>
> </configuration>
>
>
>> 3) notify the list about what I have found
>
> With the changes outlined above, everything runs correctly and seems to
> give correct results. There is however something strange: for all
> multi-module components (digester, functor, vhs, chain), no coverage
> reports are generated and the surefire report shows 0 tests. I still
> think this is expected behaviour because when I revert to commons-parent
> 28, I get exactly the same thing: no tests reported at the main site
> level. I think this is due to the tests being done in modules. There is
> probably something to improve there, but it is already wrong with
> commons-parent 28.
>
> [launcher] and [daemon] do not report tests either, but I think it is
> normal too despite they are not multi-module (they do not seem to have
> automatic tests).
>
> [pool] works well, but since it already have an independent cobertura
> setting in the pom, we get two coverage reports: one from jacoco and one
> from cobertura!
>
> I was not able to run [dbcp] because my local configuration does not
> include a Java 7 environment (I should probably upgrade ...)
>
> I was not able to build [proxy] due to some maven errors. I did not get
> the same error with commons-parent 29-SNAPSHOT and with commons-parent
> 28, but in both cases I get an error.
>
>
>> 4) release parent pom with the current status
>> (i.e. with only jacoco and surefire updated)
>
> Looking at the result of these tests and the fact none of the failures
> seem to be due to commons-parent 29, I will probably cut a release
> candidate for commons parent 29 tomorrow.
There are some possible plugin updates:
[INFO] maven-changes-plugin ..................................... 2.8 -> 2.9
[INFO] maven-compiler-plugin .................................... 3.0 -> 3.1
[INFO] maven-release-plugin ................................. 2.3.2 -> 2.4.1
[INFO] org.apache.rat:apache-rat-plugin ......................... 0.8 -> 0.9
>> 5) update the component pom with problems
>> 6) help others if I missed some components problems
>
> best regards,
> Luc
>
>>
>> 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 <luc@spaceroots.org
>>>>>
>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Gary Gregory <ga...@gmail.com> a écrit :
>>>>>>>>>>>>
>>>>>>>>>>>>> On Wed, May 8, 2013 at 3:58 PM, Luc Maisonobe
>>>>>>>>>> <Lu...@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 <lu...@spaceroots.org>
>>>> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Le 2013-04-05 00:10, Gary Gregory a écrit :
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On Thu, Apr 4, 2013 at 4:03 PM, sebb <se...@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-unsubscribe@commons.apache.org>
>>>>>>>>>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>
>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> Envoyé de mon téléphone Android avec K-9 Mail. Excusez la
>>>> brièveté.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>
>>>> ---------------------------------------------------------------------
>>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> E-Mail: garydgregory@gmail.com | ggregory@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-unsubscribe@commons.apache.org
>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> E-Mail: garydgregory@gmail.com | ggregory@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-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>>>
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [ALL] Cobertura and Parent POM
Posted by Luc Maisonobe <lu...@spaceroots.org>.
Le 11/05/2013 23:25, Luc Maisonobe a écrit :
> Le 11/05/2013 15:45, Gary Gregory a écrit :
>> On Sat, May 11, 2013 at 9:02 AM, sebb <se...@gmail.com> wrote:
>>
>>> On 11 May 2013 13:25, Gary Gregory <ga...@gmail.com> wrote:
>>>> On Fri, May 10, 2013 at 3:51 PM, Luc Maisonobe <Luc.Maisonobe@free.fr
>>>> wrote:
>>>>
>>>>> Hi Sebb,
>>>>>
>>>>> Le 09/05/2013 20:03, sebb a écrit :
>>>>>> On 9 May 2013 18:28, Luc Maisonobe <lu...@spaceroots.org> wrote:
>>>>>>> Hi all,
>>>>>>>
>>>>>>> Le 08/05/2013 22:46, Luc Maisonobe a écrit :
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Gary Gregory <ga...@gmail.com> a écrit :
>>>>>>>>
>>>>>>>>> On Wed, May 8, 2013 at 4:32 PM, Gary Gregory <
>>> garydgregory@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
I have done this for almost all proper components (bcel beanutils
betwixt bsf chain cli codec collections compress configuration csv
daemon dbcp dbutils digester discovery el email exec fileupload functor
imaging io jci jcs jexl jxpath lang launcher logging math modeler net
ognl pool primitives proxy scxml validator vfs).
> 2) in case of problems, find how to change the components pom
The needed changes were:
[beanutils], [imaging], [io], [jcs], [ognl] : add the ${argLine}
variable in the <argLine> configuration for surefire.
This change may also been added to [configuration] and [lang], but in
fact the change is in a commented out part of the pom.
A specific change for [logging] is due to the fact it completely
disables test coverage, so we need to disable jacoco instead of
disabling cobertura. The change is therefore to replace
<groupId>org.codehaus.mojo</groupId>
<artifactId>cobertura-maven-plugin</artifactId>
<version>${commons.cobertura.version}</version>
<configuration>
<skip>true</skip>
</configuration>
with
<groupId>org.jacoco</groupId>
<artifactId>jacoco-maven-plugin</artifactId>
<version>${commons.jacoco.version}</version>
<configuration>
<skip>true</skip>
</configuration>
> 3) notify the list about what I have found
With the changes outlined above, everything runs correctly and seems to
give correct results. There is however something strange: for all
multi-module components (digester, functor, vhs, chain), no coverage
reports are generated and the surefire report shows 0 tests. I still
think this is expected behaviour because when I revert to commons-parent
28, I get exactly the same thing: no tests reported at the main site
level. I think this is due to the tests being done in modules. There is
probably something to improve there, but it is already wrong with
commons-parent 28.
[launcher] and [daemon] do not report tests either, but I think it is
normal too despite they are not multi-module (they do not seem to have
automatic tests).
[pool] works well, but since it already have an independent cobertura
setting in the pom, we get two coverage reports: one from jacoco and one
from cobertura!
I was not able to run [dbcp] because my local configuration does not
include a Java 7 environment (I should probably upgrade ...)
I was not able to build [proxy] due to some maven errors. I did not get
the same error with commons-parent 29-SNAPSHOT and with commons-parent
28, but in both cases I get an error.
> 4) release parent pom with the current status
> (i.e. with only jacoco and surefire updated)
Looking at the result of these tests and the fact none of the failures
seem to be due to commons-parent 29, I will probably cut a release
candidate for commons parent 29 tomorrow.
> 5) update the component pom with problems
> 6) help others if I missed some components problems
best regards,
Luc
>
> 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 <luc@spaceroots.org
>>>>
>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Gary Gregory <ga...@gmail.com> a écrit :
>>>>>>>>>>>
>>>>>>>>>>>> On Wed, May 8, 2013 at 3:58 PM, Luc Maisonobe
>>>>>>>>> <Lu...@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 <lu...@spaceroots.org>
>>> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Le 2013-04-05 00:10, Gary Gregory a écrit :
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On Thu, Apr 4, 2013 at 4:03 PM, sebb <se...@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-unsubscribe@commons.apache.org>
>>>>>>>>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>
>>> ---------------------------------------------------------------------
>>>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> Envoyé de mon téléphone Android avec K-9 Mail. Excusez la
>>> brièveté.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>> ---------------------------------------------------------------------
>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> E-Mail: garydgregory@gmail.com | ggregory@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-unsubscribe@commons.apache.org
>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> E-Mail: garydgregory@gmail.com | ggregory@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-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [ALL] Cobertura and Parent POM
Posted by Luc Maisonobe <lu...@spaceroots.org>.
Le 11/05/2013 15:45, Gary Gregory a écrit :
> On Sat, May 11, 2013 at 9:02 AM, sebb <se...@gmail.com> wrote:
>
>> On 11 May 2013 13:25, Gary Gregory <ga...@gmail.com> wrote:
>>> On Fri, May 10, 2013 at 3:51 PM, Luc Maisonobe <Luc.Maisonobe@free.fr
>>> wrote:
>>>
>>>> Hi Sebb,
>>>>
>>>> Le 09/05/2013 20:03, sebb a écrit :
>>>>> On 9 May 2013 18:28, Luc Maisonobe <lu...@spaceroots.org> wrote:
>>>>>> Hi all,
>>>>>>
>>>>>> Le 08/05/2013 22:46, Luc Maisonobe a écrit :
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Gary Gregory <ga...@gmail.com> a écrit :
>>>>>>>
>>>>>>>> On Wed, May 8, 2013 at 4:32 PM, Gary Gregory <
>> garydgregory@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 <luc@spaceroots.org
>>>
>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Gary Gregory <ga...@gmail.com> a écrit :
>>>>>>>>>>
>>>>>>>>>>> On Wed, May 8, 2013 at 3:58 PM, Luc Maisonobe
>>>>>>>> <Lu...@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 <lu...@spaceroots.org>
>> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Le 2013-04-05 00:10, Gary Gregory a écrit :
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Thu, Apr 4, 2013 at 4:03 PM, sebb <se...@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-unsubscribe@commons.apache.org>
>>>>>>>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>
>> ---------------------------------------------------------------------
>>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Envoyé de mon téléphone Android avec K-9 Mail. Excusez la
>> brièveté.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>> ---------------------------------------------------------------------
>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> E-Mail: garydgregory@gmail.com | ggregory@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-unsubscribe@commons.apache.org
>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>
>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>>>
>>>
>>>
>>> --
>>> E-Mail: garydgregory@gmail.com | ggregory@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-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [ALL] Cobertura and Parent POM
Posted by Gary Gregory <ga...@gmail.com>.
On May 12, 2013, at 8:01, sebb <se...@gmail.com> wrote:
> On 11 May 2013 14:45, Gary Gregory <ga...@gmail.com> wrote:
>> On Sat, May 11, 2013 at 9:02 AM, sebb <se...@gmail.com> wrote:
>>
>>> On 11 May 2013 13:25, Gary Gregory <ga...@gmail.com> wrote:
>>>> On Fri, May 10, 2013 at 3:51 PM, Luc Maisonobe <Luc.Maisonobe@free.fr
>>>> wrote:
>>>>
>>>>> Hi Sebb,
>>>>>
>>>>> Le 09/05/2013 20:03, sebb a écrit :
>>>>>> On 9 May 2013 18:28, Luc Maisonobe <lu...@spaceroots.org> wrote:
>>>>>>> Hi all,
>>>>>>>
>>>>>>> Le 08/05/2013 22:46, Luc Maisonobe a écrit :
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Gary Gregory <ga...@gmail.com> a écrit :
>>>>>>>>
>>>>>>>>> On Wed, May 8, 2013 at 4:32 PM, Gary Gregory <
>>> garydgregory@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 <luc@spaceroots.org
>>>>
>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Gary Gregory <ga...@gmail.com> a écrit :
>>>>>>>>>>>
>>>>>>>>>>>> On Wed, May 8, 2013 at 3:58 PM, Luc Maisonobe
>>>>>>>>> <Lu...@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 <lu...@spaceroots.org>
>>> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Le 2013-04-05 00:10, Gary Gregory a écrit :
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On Thu, Apr 4, 2013 at 4:03 PM, sebb <se...@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-unsubscribe@commons.apache.org>
>>>>>>>>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>> ---------------------------------------------------------------------
>>>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> Envoyé de mon téléphone Android avec K-9 Mail. Excusez la
>>> brièveté.
>>> ---------------------------------------------------------------------
>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> E-Mail: garydgregory@gmail.com | ggregory@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-unsubscribe@commons.apache.org
>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>>>
>>>> --
>>>> E-Mail: garydgregory@gmail.com | ggregory@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-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>> --
>> E-Mail: garydgregory@gmail.com | ggregory@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-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [ALL] Cobertura and Parent POM
Posted by sebb <se...@gmail.com>.
On 11 May 2013 14:45, Gary Gregory <ga...@gmail.com> wrote:
> On Sat, May 11, 2013 at 9:02 AM, sebb <se...@gmail.com> wrote:
>
>> On 11 May 2013 13:25, Gary Gregory <ga...@gmail.com> wrote:
>> > On Fri, May 10, 2013 at 3:51 PM, Luc Maisonobe <Luc.Maisonobe@free.fr
>> >wrote:
>> >
>> >> Hi Sebb,
>> >>
>> >> Le 09/05/2013 20:03, sebb a écrit :
>> >> > On 9 May 2013 18:28, Luc Maisonobe <lu...@spaceroots.org> wrote:
>> >> >> Hi all,
>> >> >>
>> >> >> Le 08/05/2013 22:46, Luc Maisonobe a écrit :
>> >> >>>
>> >> >>>
>> >> >>>
>> >> >>> Gary Gregory <ga...@gmail.com> a écrit :
>> >> >>>
>> >> >>>> On Wed, May 8, 2013 at 4:32 PM, Gary Gregory <
>> garydgregory@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 <luc@spaceroots.org
>> >
>> >> >>>> wrote:
>> >> >>>>>
>> >> >>>>>>
>> >> >>>>>>
>> >> >>>>>>
>> >> >>>>>> Gary Gregory <ga...@gmail.com> a écrit :
>> >> >>>>>>
>> >> >>>>>>> On Wed, May 8, 2013 at 3:58 PM, Luc Maisonobe
>> >> >>>> <Lu...@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 <lu...@spaceroots.org>
>> wrote:
>> >> >>>>>>>>>
>> >> >>>>>>>>>> Le 2013-04-05 00:10, Gary Gregory a écrit :
>> >> >>>>>>>>>>
>> >> >>>>>>>>>>> On Thu, Apr 4, 2013 at 4:03 PM, sebb <se...@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-unsubscribe@commons.apache.org>
>> >> >>>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>> >> >>>>>>>>>>
>> >> >>>>>>>>>>
>> >> >>>>>>>>>
>> >> >>>>>>>>>
>> >> >>>>>>>>
>> >> >>>>>>>>
>> >> >>>>>>>>
>> >> >>>>
>> ---------------------------------------------------------------------
>> >> >>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> >> >>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>> >> >>>>>>>>
>> >> >>>>>>>>
>> >> >>>>>>
>> >> >>>>>> --
>> >> >>>>>> Envoyé de mon téléphone Android avec K-9 Mail. Excusez la
>> brièveté.
>> >> >>>>>>
>> >> >>>>>>
>> >> >>>>
>> ---------------------------------------------------------------------
>> >> >>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> >> >>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>> >> >>>>>>
>> >> >>>>>>
>> >> >>>>>
>> >> >>>>>
>> >> >>>>> --
>> >> >>>>> E-Mail: garydgregory@gmail.com | ggregory@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-unsubscribe@commons.apache.org
>> >> >> For additional commands, e-mail: dev-help@commons.apache.org
>> >> >>
>> >> >
>> >> > ---------------------------------------------------------------------
>> >> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> >> > For additional commands, e-mail: dev-help@commons.apache.org
>> >> >
>> >> >
>> >>
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> >> For additional commands, e-mail: dev-help@commons.apache.org
>> >>
>> >>
>> >
>> >
>> > --
>> > E-Mail: garydgregory@gmail.com | ggregory@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-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
>
> --
> E-Mail: garydgregory@gmail.com | ggregory@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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [ALL] Cobertura and Parent POM
Posted by Gary Gregory <ga...@gmail.com>.
On Sat, May 11, 2013 at 9:02 AM, sebb <se...@gmail.com> wrote:
> On 11 May 2013 13:25, Gary Gregory <ga...@gmail.com> wrote:
> > On Fri, May 10, 2013 at 3:51 PM, Luc Maisonobe <Luc.Maisonobe@free.fr
> >wrote:
> >
> >> Hi Sebb,
> >>
> >> Le 09/05/2013 20:03, sebb a écrit :
> >> > On 9 May 2013 18:28, Luc Maisonobe <lu...@spaceroots.org> wrote:
> >> >> Hi all,
> >> >>
> >> >> Le 08/05/2013 22:46, Luc Maisonobe a écrit :
> >> >>>
> >> >>>
> >> >>>
> >> >>> Gary Gregory <ga...@gmail.com> a écrit :
> >> >>>
> >> >>>> On Wed, May 8, 2013 at 4:32 PM, Gary Gregory <
> garydgregory@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. ;)
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 <luc@spaceroots.org
> >
> >> >>>> wrote:
> >> >>>>>
> >> >>>>>>
> >> >>>>>>
> >> >>>>>>
> >> >>>>>> Gary Gregory <ga...@gmail.com> a écrit :
> >> >>>>>>
> >> >>>>>>> On Wed, May 8, 2013 at 3:58 PM, Luc Maisonobe
> >> >>>> <Lu...@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 <lu...@spaceroots.org>
> wrote:
> >> >>>>>>>>>
> >> >>>>>>>>>> Le 2013-04-05 00:10, Gary Gregory a écrit :
> >> >>>>>>>>>>
> >> >>>>>>>>>>> On Thu, Apr 4, 2013 at 4:03 PM, sebb <se...@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-unsubscribe@commons.apache.org>
> >> >>>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
> >> >>>>>>>>>>
> >> >>>>>>>>>>
> >> >>>>>>>>>
> >> >>>>>>>>>
> >> >>>>>>>>
> >> >>>>>>>>
> >> >>>>>>>>
> >> >>>>
> ---------------------------------------------------------------------
> >> >>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >> >>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
> >> >>>>>>>>
> >> >>>>>>>>
> >> >>>>>>
> >> >>>>>> --
> >> >>>>>> Envoyé de mon téléphone Android avec K-9 Mail. Excusez la
> brièveté.
> >> >>>>>>
> >> >>>>>>
> >> >>>>
> ---------------------------------------------------------------------
> >> >>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >> >>>>>> For additional commands, e-mail: dev-help@commons.apache.org
> >> >>>>>>
> >> >>>>>>
> >> >>>>>
> >> >>>>>
> >> >>>>> --
> >> >>>>> E-Mail: garydgregory@gmail.com | ggregory@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-unsubscribe@commons.apache.org
> >> >> For additional commands, e-mail: dev-help@commons.apache.org
> >> >>
> >> >
> >> > ---------------------------------------------------------------------
> >> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >> > For additional commands, e-mail: dev-help@commons.apache.org
> >> >
> >> >
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >> For additional commands, e-mail: dev-help@commons.apache.org
> >>
> >>
> >
> >
> > --
> > E-Mail: garydgregory@gmail.com | ggregory@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-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
E-Mail: garydgregory@gmail.com | ggregory@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
Re: [ALL] Cobertura and Parent POM
Posted by sebb <se...@gmail.com>.
On 11 May 2013 13:25, Gary Gregory <ga...@gmail.com> wrote:
> On Fri, May 10, 2013 at 3:51 PM, Luc Maisonobe <Lu...@free.fr>wrote:
>
>> Hi Sebb,
>>
>> Le 09/05/2013 20:03, sebb a écrit :
>> > On 9 May 2013 18:28, Luc Maisonobe <lu...@spaceroots.org> wrote:
>> >> Hi all,
>> >>
>> >> Le 08/05/2013 22:46, Luc Maisonobe a écrit :
>> >>>
>> >>>
>> >>>
>> >>> Gary Gregory <ga...@gmail.com> a écrit :
>> >>>
>> >>>> On Wed, May 8, 2013 at 4:32 PM, Gary Gregory <ga...@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 <lu...@spaceroots.org>
>> >>>> wrote:
>> >>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>> Gary Gregory <ga...@gmail.com> a écrit :
>> >>>>>>
>> >>>>>>> On Wed, May 8, 2013 at 3:58 PM, Luc Maisonobe
>> >>>> <Lu...@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 <lu...@spaceroots.org> wrote:
>> >>>>>>>>>
>> >>>>>>>>>> Le 2013-04-05 00:10, Gary Gregory a écrit :
>> >>>>>>>>>>
>> >>>>>>>>>>> On Thu, Apr 4, 2013 at 4:03 PM, sebb <se...@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-unsubscribe@commons.apache.org>
>> >>>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>>
>> >>>> ---------------------------------------------------------------------
>> >>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> >>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>
>> >>>>>> --
>> >>>>>> Envoyé de mon téléphone Android avec K-9 Mail. Excusez la brièveté.
>> >>>>>>
>> >>>>>>
>> >>>> ---------------------------------------------------------------------
>> >>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> >>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>> >>>>>>
>> >>>>>>
>> >>>>>
>> >>>>>
>> >>>>> --
>> >>>>> E-Mail: garydgregory@gmail.com | ggregory@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-unsubscribe@commons.apache.org
>> >> For additional commands, e-mail: dev-help@commons.apache.org
>> >>
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> > For additional commands, e-mail: dev-help@commons.apache.org
>> >
>> >
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
>
> --
> E-Mail: garydgregory@gmail.com | ggregory@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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [ALL] Cobertura and Parent POM
Posted by Gary Gregory <ga...@gmail.com>.
On Fri, May 10, 2013 at 3:51 PM, Luc Maisonobe <Lu...@free.fr>wrote:
> Hi Sebb,
>
> Le 09/05/2013 20:03, sebb a écrit :
> > On 9 May 2013 18:28, Luc Maisonobe <lu...@spaceroots.org> wrote:
> >> Hi all,
> >>
> >> Le 08/05/2013 22:46, Luc Maisonobe a écrit :
> >>>
> >>>
> >>>
> >>> Gary Gregory <ga...@gmail.com> a écrit :
> >>>
> >>>> On Wed, May 8, 2013 at 4:32 PM, Gary Gregory <ga...@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.
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" ;)
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 <lu...@spaceroots.org>
> >>>> wrote:
> >>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> Gary Gregory <ga...@gmail.com> a écrit :
> >>>>>>
> >>>>>>> On Wed, May 8, 2013 at 3:58 PM, Luc Maisonobe
> >>>> <Lu...@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 <lu...@spaceroots.org> wrote:
> >>>>>>>>>
> >>>>>>>>>> Le 2013-04-05 00:10, Gary Gregory a écrit :
> >>>>>>>>>>
> >>>>>>>>>>> On Thu, Apr 4, 2013 at 4:03 PM, sebb <se...@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-unsubscribe@commons.apache.org>
> >>>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>> ---------------------------------------------------------------------
> >>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
> >>>>>>>>
> >>>>>>>>
> >>>>>>
> >>>>>> --
> >>>>>> Envoyé de mon téléphone Android avec K-9 Mail. Excusez la brièveté.
> >>>>>>
> >>>>>>
> >>>> ---------------------------------------------------------------------
> >>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >>>>>> For additional commands, e-mail: dev-help@commons.apache.org
> >>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>> --
> >>>>> E-Mail: garydgregory@gmail.com | ggregory@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-unsubscribe@commons.apache.org
> >> For additional commands, e-mail: dev-help@commons.apache.org
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
E-Mail: garydgregory@gmail.com | ggregory@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
Re: [ALL] Cobertura and Parent POM
Posted by Luc Maisonobe <Lu...@free.fr>.
Hi Sebb,
Le 09/05/2013 20:03, sebb a écrit :
> On 9 May 2013 18:28, Luc Maisonobe <lu...@spaceroots.org> wrote:
>> Hi all,
>>
>> Le 08/05/2013 22:46, Luc Maisonobe a écrit :
>>>
>>>
>>>
>>> Gary Gregory <ga...@gmail.com> a écrit :
>>>
>>>> On Wed, May 8, 2013 at 4:32 PM, Gary Gregory <ga...@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 <lu...@spaceroots.org>
>>>> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Gary Gregory <ga...@gmail.com> a écrit :
>>>>>>
>>>>>>> On Wed, May 8, 2013 at 3:58 PM, Luc Maisonobe
>>>> <Lu...@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 <lu...@spaceroots.org> wrote:
>>>>>>>>>
>>>>>>>>>> Le 2013-04-05 00:10, Gary Gregory a écrit :
>>>>>>>>>>
>>>>>>>>>>> On Thu, Apr 4, 2013 at 4:03 PM, sebb <se...@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-unsubscribe@commons.apache.org>
>>>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>> --
>>>>>> Envoyé de mon téléphone Android avec K-9 Mail. Excusez la brièveté.
>>>>>>
>>>>>>
>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> E-Mail: garydgregory@gmail.com | ggregory@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-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [ALL] Cobertura and Parent POM
Posted by sebb <se...@gmail.com>.
On 9 May 2013 18:28, Luc Maisonobe <lu...@spaceroots.org> wrote:
> Hi all,
>
> Le 08/05/2013 22:46, Luc Maisonobe a écrit :
>>
>>
>>
>> Gary Gregory <ga...@gmail.com> a écrit :
>>
>>> On Wed, May 8, 2013 at 4:32 PM, Gary Gregory <ga...@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.
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 <lu...@spaceroots.org>
>>> wrote:
>>>>
>>>>>
>>>>>
>>>>>
>>>>> Gary Gregory <ga...@gmail.com> a écrit :
>>>>>
>>>>>> On Wed, May 8, 2013 at 3:58 PM, Luc Maisonobe
>>> <Lu...@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 <lu...@spaceroots.org> wrote:
>>>>>>>>
>>>>>>>>> Le 2013-04-05 00:10, Gary Gregory a écrit :
>>>>>>>>>
>>>>>>>>>> On Thu, Apr 4, 2013 at 4:03 PM, sebb <se...@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-unsubscribe@commons.apache.org>
>>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>
>>>>>>>
>>>>>
>>>>> --
>>>>> Envoyé de mon téléphone Android avec K-9 Mail. Excusez la brièveté.
>>>>>
>>>>>
>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> E-Mail: garydgregory@gmail.com | ggregory@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-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [ALL] Cobertura and Parent POM
Posted by Luc Maisonobe <lu...@spaceroots.org>.
Hi all,
Le 08/05/2013 22:46, Luc Maisonobe a écrit :
>
>
>
> Gary Gregory <ga...@gmail.com> a écrit :
>
>> On Wed, May 8, 2013 at 4:32 PM, Gary Gregory <ga...@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? I think several other plugin also need Java 5, but I
don't know for sure.
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 <lu...@spaceroots.org>
>> wrote:
>>>
>>>>
>>>>
>>>>
>>>> Gary Gregory <ga...@gmail.com> a écrit :
>>>>
>>>>> On Wed, May 8, 2013 at 3:58 PM, Luc Maisonobe
>> <Lu...@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 <lu...@spaceroots.org> wrote:
>>>>>>>
>>>>>>>> Le 2013-04-05 00:10, Gary Gregory a écrit :
>>>>>>>>
>>>>>>>>> On Thu, Apr 4, 2013 at 4:03 PM, sebb <se...@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-unsubscribe@commons.apache.org>
>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>
>>>>>>
>>>>
>>>> --
>>>> Envoyé de mon téléphone Android avec K-9 Mail. Excusez la brièveté.
>>>>
>>>>
>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>>>
>>>
>>>
>>> --
>>> E-Mail: garydgregory@gmail.com | ggregory@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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [ALL] Cobertura and Parent POM
Posted by Luc Maisonobe <lu...@spaceroots.org>.
Gary Gregory <ga...@gmail.com> a écrit :
>On Wed, May 8, 2013 at 4:32 PM, Gary Gregory <ga...@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".
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 <lu...@spaceroots.org>
>wrote:
>>
>>>
>>>
>>>
>>> Gary Gregory <ga...@gmail.com> a écrit :
>>>
>>> >On Wed, May 8, 2013 at 3:58 PM, Luc Maisonobe
><Lu...@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 <lu...@spaceroots.org> wrote:
>>> >> >
>>> >> >> Le 2013-04-05 00:10, Gary Gregory a écrit :
>>> >> >>
>>> >> >>> On Thu, Apr 4, 2013 at 4:03 PM, sebb <se...@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-unsubscribe@commons.apache.org>
>>> >> >> For additional commands, e-mail: dev-help@commons.apache.org
>>> >> >>
>>> >> >>
>>> >> >
>>> >> >
>>> >>
>>> >>
>>> >>
>---------------------------------------------------------------------
>>> >> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> >> For additional commands, e-mail: dev-help@commons.apache.org
>>> >>
>>> >>
>>>
>>> --
>>> Envoyé de mon téléphone Android avec K-9 Mail. Excusez la brièveté.
>>>
>>>
>---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>>
>>
>> --
>> E-Mail: garydgregory@gmail.com | ggregory@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
>>
--
Envoyé de mon téléphone Android avec K-9 Mail. Excusez la brièveté.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [ALL] Cobertura and Parent POM
Posted by Gary Gregory <ga...@gmail.com>.
On Wed, May 8, 2013 at 4:32 PM, Gary Gregory <ga...@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".
Gary
>
> Gary
>
>
> On Wed, May 8, 2013 at 4:18 PM, Luc Maisonobe <lu...@spaceroots.org> wrote:
>
>>
>>
>>
>> Gary Gregory <ga...@gmail.com> a écrit :
>>
>> >On Wed, May 8, 2013 at 3:58 PM, Luc Maisonobe <Lu...@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 <lu...@spaceroots.org> wrote:
>> >> >
>> >> >> Le 2013-04-05 00:10, Gary Gregory a écrit :
>> >> >>
>> >> >>> On Thu, Apr 4, 2013 at 4:03 PM, sebb <se...@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-unsubscribe@commons.apache.org>
>> >> >> For additional commands, e-mail: dev-help@commons.apache.org
>> >> >>
>> >> >>
>> >> >
>> >> >
>> >>
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> >> For additional commands, e-mail: dev-help@commons.apache.org
>> >>
>> >>
>>
>> --
>> Envoyé de mon téléphone Android avec K-9 Mail. Excusez la brièveté.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
>
> --
> E-Mail: garydgregory@gmail.com | ggregory@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
>
--
E-Mail: garydgregory@gmail.com | ggregory@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
Re: [ALL] Cobertura and Parent POM
Posted by Gary Gregory <ga...@gmail.com>.
In the Maven output I see:
[INFO] Skipping JaCoCo execution due to missing execution data file
Gary
On Wed, May 8, 2013 at 4:18 PM, Luc Maisonobe <lu...@spaceroots.org> wrote:
>
>
>
> Gary Gregory <ga...@gmail.com> a écrit :
>
> >On Wed, May 8, 2013 at 3:58 PM, Luc Maisonobe <Lu...@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 <lu...@spaceroots.org> wrote:
> >> >
> >> >> Le 2013-04-05 00:10, Gary Gregory a écrit :
> >> >>
> >> >>> On Thu, Apr 4, 2013 at 4:03 PM, sebb <se...@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-unsubscribe@commons.apache.org>
> >> >> For additional commands, e-mail: dev-help@commons.apache.org
> >> >>
> >> >>
> >> >
> >> >
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >> For additional commands, e-mail: dev-help@commons.apache.org
> >>
> >>
>
> --
> Envoyé de mon téléphone Android avec K-9 Mail. Excusez la brièveté.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
E-Mail: garydgregory@gmail.com | ggregory@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
Re: [ALL] Cobertura and Parent POM
Posted by Luc Maisonobe <lu...@spaceroots.org>.
Gary Gregory <ga...@gmail.com> a écrit :
>On Wed, May 8, 2013 at 3:58 PM, Luc Maisonobe <Lu...@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 <lu...@spaceroots.org> wrote:
>> >
>> >> Le 2013-04-05 00:10, Gary Gregory a écrit :
>> >>
>> >>> On Thu, Apr 4, 2013 at 4:03 PM, sebb <se...@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-unsubscribe@commons.apache.org>
>> >> For additional commands, e-mail: dev-help@commons.apache.org
>> >>
>> >>
>> >
>> >
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
--
Envoyé de mon téléphone Android avec K-9 Mail. Excusez la brièveté.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [ALL] Cobertura and Parent POM
Posted by Gary Gregory <ga...@gmail.com>.
On Wed, May 8, 2013 at 3:58 PM, Luc Maisonobe <Lu...@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.
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 <lu...@spaceroots.org> wrote:
> >
> >> Le 2013-04-05 00:10, Gary Gregory a écrit :
> >>
> >>> On Thu, Apr 4, 2013 at 4:03 PM, sebb <se...@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-unsubscribe@commons.apache.org>
> >> For additional commands, e-mail: dev-help@commons.apache.org
> >>
> >>
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
E-Mail: garydgregory@gmail.com | ggregory@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
Re: [ALL] Cobertura and Parent POM
Posted by Luc Maisonobe <Lu...@free.fr>.
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"? Don't you have the skipReports
property set to true?
Luc
>
> Gary
>
>
> On Fri, Apr 5, 2013 at 7:44 AM, luc <lu...@spaceroots.org> wrote:
>
>> Le 2013-04-05 00:10, Gary Gregory a écrit :
>>
>>> On Thu, Apr 4, 2013 at 4:03 PM, sebb <se...@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<de...@commons.apache.org>
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [ALL] Cobertura and Parent POM
Posted by Gary Gregory <ga...@gmail.com>.
I updated my local commons-io to 29-SNAPSHOT and I do not see a coverage
report.
How is that fixed?
Gary
On Fri, Apr 5, 2013 at 7:44 AM, luc <lu...@spaceroots.org> wrote:
> Le 2013-04-05 00:10, Gary Gregory a écrit :
>
>> On Thu, Apr 4, 2013 at 4:03 PM, sebb <se...@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<de...@commons.apache.org>
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
E-Mail: garydgregory@gmail.com | ggregory@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
Re: [ALL] Cobertura and Parent POM
Posted by luc <lu...@spaceroots.org>.
Le 2013-04-05 00:10, Gary Gregory a écrit :
> On Thu, Apr 4, 2013 at 4:03 PM, sebb <se...@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
For additional commands, e-mail: dev-help@commons.apache.org
Re: [ALL] Cobertura and Parent POM
Posted by Gary Gregory <ga...@gmail.com>.
On Thu, Apr 4, 2013 at 4:03 PM, sebb <se...@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?
Gary
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
JUnit in Action, 2nd Ed: <http://goog_1249600977>http://bit.ly/ECvg0
Spring Batch in Action: <http://s.apache.org/HOq>http://bit.ly/bqpbCK
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Re: [ALL] Cobertura and Parent POM
Posted by Adrian Crum <ad...@sandglass-software.com>.
Thank you for working on this.
The original proposal was to replace Cobertura with something else. I
asked that the sub projects have an option to use whatever reporting
tool they want. So, it would be fine if some other reporting tool was
the default as long as sub projects can use something else.
-Adrian
On 4/4/2013 9:03 PM, sebb 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.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [ALL] Cobertura and Parent POM
Posted by Luc Maisonobe <Lu...@free.fr>.
Hi all,
Le 05/04/2013 22:49, Gary Gregory a écrit :
> On Fri, Apr 5, 2013 at 4:30 PM, Phil Steitz <ph...@gmail.com> wrote:
>
>> On 4/4/13 1:03 PM, sebb 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.
>> +1
>>>
>>> However, I think it is important that some code coverage tool is used.
>>
>> I would say let components decide whether they want to a) include
>> something b) use Sonar c) nothing.
>>
>
> All components 'should' provide coverage reports IMO, so configure one in
> parent. If you really do not want one, then you have to 'configure by
> exception' and remove it.
>
> I think we are to the point now where we want to say goodbye to Cobertura
> and hello to Jacoco.
I'm reviving this thread one month later.
I have committed the necessary changes in commons-parent pom. I tried
this on [math] and it works great! No changes required in the components
pom (except of course updating parent pom to 29-SNAPSHOT and
making sure it is lacally installed).
The reports are perfectly inserted in the reporting section when we run
"mvn site".
The most important facts are:
- it is *much* faster (the two most time-consuming tests in [math] are
still commented out, but even in this configuration, running "mvn
site" took 4 hours on my machine before the changes (it took 9 hours
with the two tests activated), now it takes 9 minutes!
- the bunch of weird errors due to wrong parsing of some litteral
constants (due to cobertura using an obsolete version of javacc)
are now gone
Could someone check how it works on other components?
Do you think we could release version 29 of commons parent pom?
Best regards,
Luc
>
> Gary
>
>
>>
>> Phil
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [ALL] Cobertura and Parent POM
Posted by Gary Gregory <ga...@gmail.com>.
On Fri, Apr 5, 2013 at 4:30 PM, Phil Steitz <ph...@gmail.com> wrote:
> On 4/4/13 1:03 PM, sebb 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.
> +1
> >
> > However, I think it is important that some code coverage tool is used.
>
> I would say let components decide whether they want to a) include
> something b) use Sonar c) nothing.
>
All components 'should' provide coverage reports IMO, so configure one in
parent. If you really do not want one, then you have to 'configure by
exception' and remove it.
I think we are to the point now where we want to say goodbye to Cobertura
and hello to Jacoco.
Gary
>
> Phil
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
JUnit in Action, 2nd Ed: <http://goog_1249600977>http://bit.ly/ECvg0
Spring Batch in Action: <http://s.apache.org/HOq>http://bit.ly/bqpbCK
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Re: [ALL] Cobertura and Parent POM
Posted by Phil Steitz <ph...@gmail.com>.
On 4/4/13 1:03 PM, sebb 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.
+1
>
> However, I think it is important that some code coverage tool is used.
I would say let components decide whether they want to a) include
something b) use Sonar c) nothing.
Phil
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [ALL] Cobertura and Parent POM
Posted by "Honton, Charles" <Ch...@intuit.com>.
I recommend changing code coverage to jacoco with a skip.jacoco property.
[see
http://mail-archives.apache.org/mod_mbox/commons-dev/201303.mbox/%3CCD7CB15
7.23020%25charles_honton%40intuit.com%3E for reasons]
Regards,
chas
On 4/4/13 1:03 PM, "sebb" <se...@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.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org