Re: BookKeeper and code-coverage - JaCoco

2018-02-19 Thread Sijie Guo 
On Mon, Feb 19, 2018 at 12:23 AM, Enrico Olivelli 
wrote:

> News:
> I am struggling to create an aggregate code coverage report, but actually I
> have troubles with (I suspect) PowerMock, which is changing classes at
> runtime.
>
> The goal of an aggregate report is to consider in the report test cases
> which "test" classes which are not bundled within the same maven project.
>
> After running thru the codebase many times I have some points:
> - there is no much value in having unit tests which test code outside the
> same module and it is a bad practice
> - bookkeeper does not contain many cases (I cannot directly find any, but I
> did not spend time on this), I think that most of the cases are about
> classes moved to utility modules.
>
> Given these points I think we can step over the 'aggregate code coverage
> report" and move forward with  'classic' code coverage reporting for
> Maven/JaCoCo: each module report must be self contained,
> With this approach we are at 72% code coverage (given Coverall.io KPIs) and
> there is already much work to do in order to tidy up our codebase.
>
> So my proposal:
> - setup a definitive code coverage system, with classic code-coverage
> report
> - tidy up (during 4.8)
> - when we are okay we can see if there is real need to introduce
> multi-project report (I hope it won't be needed after tidying up)
>
> If my proposal is good I will clean up the patch:
> - remove aggregate reporting
> - enable the report on DL part of code base

- submit patch for review
>
> Then once the patch is merged:
> - setup final CI test jobs
> - submit patch for final Jenkins CI jobs using Jenkins DSL
>
> Thoughts ?
>

sgtm.


>
>
> Enrico
>
> 2018-02-15 13:47 GMT+01:00 Sijie Guo :
>
> > ack
> >
> > On Thu, Feb 15, 2018 at 2:15 PM, Enrico Olivelli 
> > wrote:
> >
> > > Il mer 14 feb 2018, 23:35 Sijie Guo  ha scritto:
> > >
> > > > Well done, Enrico!
> > > >
> > > > It seems the CI job seems to be ready to get in. Can you make the
> > Jenkins
> > > > job as part of .test-infra?
> > > >
> > >
> > > No, it s not working well.
> > > I am working on a new maven module which will aggregate the reports of
> > all
> > > upstream projects but actually it is failing. I have some idea but not
> > much
> > > time, I am moving on but it will time some other iteration
> > >
> > > Enrico
> > >
> > >
> > > > - Sijie
> > > >
> > > > On Thu, Feb 15, 2018 at 5:55 AM, Enrico Olivelli <
> eolive...@gmail.com>
> > > > wrote:
> > > >
> > > > > I have to clean up the patch but actually code coverage report
> makes
> > > > sense
> > > > > and it is reporting a 72% code coverage (using coveralls.io KPI).
> > > > > Most cases of non covered code are about:
> > > > > - classes which do not have test cases in the same module (I am
> > working
> > > > on
> > > > > this)
> > > > > - classes which are not abstact but contains only constants or
> > utility
> > > > > methods
> > > > > - interfaces, default methods
> > > > > - Circe and NativeIO
> > > > >
> > > > > Please note that generated code like protobuf, nar or lombok is
> > already
> > > > > excluded in the current WIP patch.
> > > > >
> > > > > See https://coveralls.io/builds/15432041
> > > > >
> > > > > I think that with little work we can fill most of the gaps, at
> least
> > > > > cleaning up the noise.
> > > > >
> > > > > I need to finish the work about classes not tested in the same
> > package
> > > > then
> > > > > we will be able to draw a roadmap, creating subtask for missing
> test
> > > > cases,
> > > > > cleaning up interfaces.
> > > > >
> > > > > Enrico
> > > > >
> > > > > Il dom 11 feb 2018, 17:43 Enrico Olivelli  ha
> > > > > scritto:
> > > > >
> > > > > > Created this job on CI
> > > > > >
> > > > > > https://builds.apache.org/job/bookkeeper-code-coverage-wip/
> > > > > >
> > > > > > I am working on a way to create a better report, using this
> > > suggestion
> > > > > >
> > > > > > http://www.lorenzobettini.it/2017/02/jacoco-code-coverage-
> > > > > and-report-of-multiple-eclipse-plug-in-projects/
> > > > > >
> > > > > > Build takes really long time with JaCoCo instrumentation, so I
> will
> > > use
> > > > > > Apache CI
> > > > > >
> > > > > > Enrico
> > > > > >
> > > > > >
> > > > > > 2018-02-07 17:24 GMT+01:00 Enrico Olivelli  >:
> > > > > >
> > > > > >>
> > > > > >>
> > > > > >> 2018-02-05 22:33 GMT+01:00 Sijie Guo :
> > > > > >>
> > > > > >>> On Mon, Feb 5, 2018 at 1:04 PM, Enrico Olivelli <
> > > eolive...@gmail.com
> > > > >
> > > > > >>> wrote:
> > > > > >>>
> > > > > >>> > Il lun 5 feb 2018, 18:11 David Rusek  ha
> > > scritto:
> > > > > >>> >
> > > > > >>> > > It sounds like we didn't do anything with the info for a
> long
> > > > time.
> > > > > >>> > Enrico,
> > > > > >>> > > I'm glad you're looking at it! Are you planning on filing
> > some
> > > > > issues
> > > > > >>>

Re: Outdated public project reference on ASF website

2018-02-19 Thread Ivan Kelly 
We need to update the doap, which is at
https://svn.apache.org/repos/asf/bookkeeper/site/trunk/content/doap_BookKeeper.rdf

On Sat, Feb 17, 2018 at 11:49 PM, Enrico Olivelli  wrote:
> Hi I just got into this, we are stuck at 2014, 4.3.0 recommended version!
>
> https://projects.apache.org/project.html?bookkeeper
>
> Anyone knows how to update?
>
> Enrico
> --
>
>
> -- Enrico Olivelli

Re: BookKeeper and code-coverage - JaCoco

2018-02-19 Thread Enrico Olivelli 
News:
I am struggling to create an aggregate code coverage report, but actually I
have troubles with (I suspect) PowerMock, which is changing classes at
runtime.

The goal of an aggregate report is to consider in the report test cases
which "test" classes which are not bundled within the same maven project.

After running thru the codebase many times I have some points:
- there is no much value in having unit tests which test code outside the
same module and it is a bad practice
- bookkeeper does not contain many cases (I cannot directly find any, but I
did not spend time on this), I think that most of the cases are about
classes moved to utility modules.

Given these points I think we can step over the 'aggregate code coverage
report" and move forward with  'classic' code coverage reporting for
Maven/JaCoCo: each module report must be self contained,
With this approach we are at 72% code coverage (given Coverall.io KPIs) and
there is already much work to do in order to tidy up our codebase.

So my proposal:
- setup a definitive code coverage system, with classic code-coverage report
- tidy up (during 4.8)
- when we are okay we can see if there is real need to introduce
multi-project report (I hope it won't be needed after tidying up)

If my proposal is good I will clean up the patch:
- remove aggregate reporting
- enable the report on DL part of code base
- submit patch for review

Then once the patch is merged:
- setup final CI test jobs
- submit patch for final Jenkins CI jobs using Jenkins DSL

Thoughts ?


Enrico

2018-02-15 13:47 GMT+01:00 Sijie Guo :

> ack
>
> On Thu, Feb 15, 2018 at 2:15 PM, Enrico Olivelli 
> wrote:
>
> > Il mer 14 feb 2018, 23:35 Sijie Guo  ha scritto:
> >
> > > Well done, Enrico!
> > >
> > > It seems the CI job seems to be ready to get in. Can you make the
> Jenkins
> > > job as part of .test-infra?
> > >
> >
> > No, it s not working well.
> > I am working on a new maven module which will aggregate the reports of
> all
> > upstream projects but actually it is failing. I have some idea but not
> much
> > time, I am moving on but it will time some other iteration
> >
> > Enrico
> >
> >
> > > - Sijie
> > >
> > > On Thu, Feb 15, 2018 at 5:55 AM, Enrico Olivelli 
> > > wrote:
> > >
> > > > I have to clean up the patch but actually code coverage report makes
> > > sense
> > > > and it is reporting a 72% code coverage (using coveralls.io KPI).
> > > > Most cases of non covered code are about:
> > > > - classes which do not have test cases in the same module (I am
> working
> > > on
> > > > this)
> > > > - classes which are not abstact but contains only constants or
> utility
> > > > methods
> > > > - interfaces, default methods
> > > > - Circe and NativeIO
> > > >
> > > > Please note that generated code like protobuf, nar or lombok is
> already
> > > > excluded in the current WIP patch.
> > > >
> > > > See https://coveralls.io/builds/15432041
> > > >
> > > > I think that with little work we can fill most of the gaps, at least
> > > > cleaning up the noise.
> > > >
> > > > I need to finish the work about classes not tested in the same
> package
> > > then
> > > > we will be able to draw a roadmap, creating subtask for missing test
> > > cases,
> > > > cleaning up interfaces.
> > > >
> > > > Enrico
> > > >
> > > > Il dom 11 feb 2018, 17:43 Enrico Olivelli  ha
> > > > scritto:
> > > >
> > > > > Created this job on CI
> > > > >
> > > > > https://builds.apache.org/job/bookkeeper-code-coverage-wip/
> > > > >
> > > > > I am working on a way to create a better report, using this
> > suggestion
> > > > >
> > > > > http://www.lorenzobettini.it/2017/02/jacoco-code-coverage-
> > > > and-report-of-multiple-eclipse-plug-in-projects/
> > > > >
> > > > > Build takes really long time with JaCoCo instrumentation, so I will
> > use
> > > > > Apache CI
> > > > >
> > > > > Enrico
> > > > >
> > > > >
> > > > > 2018-02-07 17:24 GMT+01:00 Enrico Olivelli :
> > > > >
> > > > >>
> > > > >>
> > > > >> 2018-02-05 22:33 GMT+01:00 Sijie Guo :
> > > > >>
> > > > >>> On Mon, Feb 5, 2018 at 1:04 PM, Enrico Olivelli <
> > eolive...@gmail.com
> > > >
> > > > >>> wrote:
> > > > >>>
> > > > >>> > Il lun 5 feb 2018, 18:11 David Rusek  ha
> > scritto:
> > > > >>> >
> > > > >>> > > It sounds like we didn't do anything with the info for a long
> > > time.
> > > > >>> > Enrico,
> > > > >>> > > I'm glad you're looking at it! Are you planning on filing
> some
> > > > issues
> > > > >>> > > related to interpreting the coverage data and improving it?
> > > > >>> > >
> > > > >>> >
> > > > >>> >
> > > > >>> > It was long time ago when I started to experiment with
> bookkeeper
> > > > >>> codebase.
> > > > >>> > We had some problems and I had other priorities.
> > > > >>> > I will try to resume this thread on next weeks I think that the
> > > > >>> culprit of
> > > >