On 12 May 2013 21:56, Luc Maisonobe <l...@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 <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.
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 <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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
