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 <seb...@gmail.com> wrote:
>>
>>> On 11 May 2013 13:25, Gary Gregory <garydgreg...@gmail.com> wrote:
>>>> On Fri, May 10, 2013 at 3:51 PM, Luc Maisonobe <luc.maison...@free.fr
>>>> wrote:
>>>>
>>>>> Hi Sebb,
>>>>>
>>>>> Le 09/05/2013 20:03, sebb a écrit :
>>>>>> On 9 May 2013 18:28, Luc Maisonobe <l...@spaceroots.org> wrote:
>>>>>>> Hi all,
>>>>>>>
>>>>>>> Le 08/05/2013 22:46, Luc Maisonobe a écrit :
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Gary Gregory <garydgreg...@gmail.com> a écrit :
>>>>>>>>
>>>>>>>>> On Wed, May 8, 2013 at 4:32 PM, Gary Gregory <
>>> garydgreg...@gmail.com>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> In the Maven output I see:
>>>>>>>>>>
>>>>>>>>>> [INFO] Skipping JaCoCo execution due to missing execution data
>>> file
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Which I from running "mvn clean site".
>>>>>>>
>>>>>>> I found the problem.
>>>>>>> What happened is that in [io] you override the command line arguments
>>>>>>> while running tests in the maven-surefire-plugin. JaCoCo also
>>> overrides
>>>>>>> them to add an agent that will observe tests runs.
>>>>>>>
>>>>>>> In order to be able to merge both settings (the [io] settings which
>>>>>>> change the max memory using option -Xmx and the complex JaCoCo
>>> setting),
>>>>>>> then you need to change in [io] pom.xml the maven-surefire-plugin
>>>>>>> configuration from:
>>>>>>>
>>>>>>> <configuration>
>>>>>>> <forkMode>pertest</forkMode>
>>>>>>> <!-- limit memory size see IO-161 -->
>>>>>>> <argLine>-Xmx25M</argLine>
>>>>>>> ...
>>>>>>> </configuration>
>>>>>>>
>>>>>>> to:
>>>>>>>
>>>>>>> <configuration>
>>>>>>> <forkMode>pertest</forkMode>
>>>>>>> <!-- limit memory size see IO-161 -->
>>>>>>> <!-- the ${argLine} preserves jacoco agent settings (see
>>>>>>> https://github.com/jacoco/eclemma/issues/22) -->
>>>>>>> <argLine>-Xmx25M ${argLine}</argLine>
>>>>>>> ...
>>>>>>> </configuration>
>>>>>>>
>>>>>>> I have added some documentation about this in both the release notes
>>> and
>>>>>>> the pom itself.
>>>>>>>
>>>>>>>
>>>>>>> Another implication of the switch to JaCoCo is that tests must be run
>>>>>>> using Java 1.5 at least (of course, this does not imply the component
>>>>>>> code must be Java 5, only, it can still target an older version). Is
>>>>>>> this a problem?
>>>>>>
>>>>>> That is a problem.
>>>>>> For components that target 1.4 or earlier it is vital that they can be
>>>>>> compiled/tested using the relevant Java version, as well as using more
>>>>>> recent JVMs.
>>>>>>
>>>>>> Running with earlier JVMs is achieved by using a profile, so maybe
>>>>>> unsuitable profiles can be detected and used to disable JaCoCo for
>>>>>> that run.
>>>>>
>>>>> I have updated the profile so it is now automatically enabled when the
>>>>> JDK version is at least 1.5.
>>>>>
>>>>> IS there anything else I should do before starting a release candidate
>>>>> for commoms-parent 29?
>>>>>
>>>>
>>>> IMO, you should at least test this new scheme with at least one other
>>>> Commons component.
>>>
>>> +1
>>>
>>>> Since it looks like this may break some component that currently use
>>>> Cobertura and not produce a coverage report unless the POM for that
>>> project
>>>> is edited -- like in [io] for example, I suggest that you at least notify
>>>> the list of which projects will break and consider updating said projects
>>>> to match the new scheme you are putting in place. "You broke it, you
>>> bought
>>>> it" ;)
>>>
>>> However it is not the case that releasing a new CP will break any
>>> components.
>>> It is up to each component whether they update or not.
>>>
>>
>> That's true in principle but in practice, components must update at some
>> point, like for the recent SCM Pub/Sub requirement. Well, OK, you could do
>> it all in your own POM, but you get my point. ;)
>
> Yes, I get your point. So I will do the following points in order:
>
> 1) looking at a few components to see if the change breaks something
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 <l...@spaceroots.org
>>>>
>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Gary Gregory <garydgreg...@gmail.com> a écrit :
>>>>>>>>>>>
>>>>>>>>>>>> On Wed, May 8, 2013 at 3:58 PM, Luc Maisonobe
>>>>>>>>> <luc.maison...@free.fr>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> Le 08/05/2013 21:11, Gary Gregory a écrit :
>>>>>>>>>>>>>> I updated my local commons-io to 29-SNAPSHOT and I do not see
>>> a
>>>>>>>>>>>> coverage
>>>>>>>>>>>>>> report.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> How is that fixed?
>>>>>>>>>>>>>
>>>>>>>>>>>>> Well, I did not have to do anything for [math]. Did you install
>>>>>>>>> the
>>>>>>>>>>>>> snapshot locally with "mvn install"?
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Yep.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> Don't you have the skipReports
>>>>>>>>>>>>> property set to true?
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Well, I do not think so, all of the other reports were generated
>>>>>>>>> with
>>>>>>>>>>>> the
>>>>>>>>>>>> site.
>>>>>>>>>>>
>>>>>>>>>>> This property triggers a profile which was used only to skip
>>>>>>>>> cobertura.
>>>>>>>>>>> So I have left this in place,
>>>>>>>>>>> which means this property does act on jacoco now, and only on
>>> jacoco
>>>>>>>>> (I'm
>>>>>>>>>>> not sure it is still useful).
>>>>>>>>>>>
>>>>>>>>>>> Luc
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> I suggest you try a couple of Commons project before pushing
>>>>>>>>> version 29
>>>>>>>>>>>> of
>>>>>>>>>>>> the parent POM.
>>>>>>>>>>>>
>>>>>>>>>>>> Gary
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> Luc
>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Gary
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Fri, Apr 5, 2013 at 7:44 AM, luc <l...@spaceroots.org>
>>> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Le 2013-04-05 00:10, Gary Gregory a écrit :
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On Thu, Apr 4, 2013 at 4:03 PM, sebb <seb...@gmail.com>
>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> CP 28 moved Cobertura to a profile called "reporting".
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> The profile was activated by default, but could be disabled
>>>>>>>>> by
>>>>>>>>>>>> using
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> -DskipReports=true
>>>>>>>>>>>>>>>>> or
>>>>>>>>>>>>>>>>> -P!reporting
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> IIRC, the idea was to move expensive (long-running) reports
>>>>>>>>> to a
>>>>>>>>>>>>> profile
>>>>>>>>>>>>>>>>> that could be disabled if necessary.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> However Cobertura causes problems with some projects, and
>>>>>>>>> the
>>>>>>>>>>>> project
>>>>>>>>>>>>>>>>> seems
>>>>>>>>>>>>>>>>> to be unmaintained, so perhaps it would be sensible to
>>>>>>>>> disable
>>>>>>>>>>>>> Cobertura
>>>>>>>>>>>>>>>>> by
>>>>>>>>>>>>>>>>> default.
>>>>>>>>>>>>>>>>> In which case the profile and property should be renamed to
>>>>>>>>>>>> reflect
>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>> fact that it only affects Cobertura.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Possibly even drop Cobertura entirely from the parent POM.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> However, I think it is important that some code coverage
>>>>>>>>> tool is
>>>>>>>>>>>> used.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> OK, but which one? I know some projects use Clover but I'd
>>>>>>>>> rather
>>>>>>>>>>>> we
>>>>>>>>>>>>> use
>>>>>>>>>>>>>>>> another FOSS tool. I know Jacoco has been mentioned.. maybe
>>>>>>>>>>>> [math]
>>>>>>>>>>>>> wants
>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>> be the guinea pig?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Yes !
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I already use Jacoco elsewhere and am very happy with it. It
>>>>>>>>> is
>>>>>>>>>>>> also
>>>>>>>>>>>>> used
>>>>>>>>>>>>>>> in our
>>>>>>>>>>>>>>> Sonar instance if I remember correctly.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The only point I had to adjust in the other project was to
>>> set
>>>>>>>>> up
>>>>>>>>>>>>> manually
>>>>>>>>>>>>>>> an entry in
>>>>>>>>>>>>>>> the site menu to point to the generated html pages, as jacoco
>>>>>>>>> was
>>>>>>>>>>>> not
>>>>>>>>>>>>>>> fully integrated
>>>>>>>>>>>>>>> in the regular reports produced by maven. Is there a complete
>>>>>>>>>>>>> integration
>>>>>>>>>>>>>>> available now?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Luc
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Gary
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>
>>> ------------------------------**------------------------------**---------
>>>>>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.**apache.org
>>> <
>>>>>>>>>>>>> dev-unsubscr...@commons.apache.org>
>>>>>>>>>>>>>>> For additional commands, e-mail: dev-h...@commons.apache.org
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>
>>> ---------------------------------------------------------------------
>>>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>>>>>>>>>>>> For additional commands, e-mail: dev-h...@commons.apache.org
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> Envoyé de mon téléphone Android avec K-9 Mail. Excusez la
>>> brièveté.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>> ---------------------------------------------------------------------
>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>>>>>>>>>> For additional commands, e-mail: dev-h...@commons.apache.org
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
>>>>>>>>>> Java Persistence with Hibernate, Second
>>>>>>>>> Edition<http://www.manning.com/bauer3/>
>>>>>>>>>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/
>>>>
>>>>>>>>>> Spring Batch in Action <http://www.manning.com/templier/>
>>>>>>>>>> Blog: http://garygregory.wordpress.com
>>>>>>>>>> Home: http://garygregory.com/
>>>>>>>>>> Tweet! http://twitter.com/GaryGregory
>>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>>>>>> For additional commands, e-mail: dev-h...@commons.apache.org
>>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>>>>> For additional commands, e-mail: dev-h...@commons.apache.org
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>>>> For additional commands, e-mail: dev-h...@commons.apache.org
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
>>>> Java Persistence with Hibernate, Second Edition<
>>> http://www.manning.com/bauer3/>
>>>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>>>> Spring Batch in Action <http://www.manning.com/templier/>
>>>> Blog: http://garygregory.wordpress.com
>>>> Home: http://garygregory.com/
>>>> Tweet! http://twitter.com/GaryGregory
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>> For additional commands, e-mail: dev-h...@commons.apache.org
>>>
>>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
