FYI, the JaCoCo team has built and end-to-end test for this feature, you
can see the improvements at
https://github.com/jacoco/jacoco/pull/610#issuecomment-337362390
>From 57% to 87% coverage, that's pretty good :-)
Thank you everyone who made this little feature happen!
Cheers,
Andres
+1 on the idea in general, obviously there's a few more details to work out
yet. I have some similar concerns to Cédric but I guess we can address
those as we go.
Cheers, Paul.
On Mon, Sep 25, 2017 at 11:08 PM, Andres Almiray wrote:
> BTW, I met with a couple of SonarSource engineers last week
BTW, I met with a couple of SonarSource engineers last week in Geneva
during a presentation at Geneva JUG.
The topic of code coverage with JaCoCo and Groovy came up. They told me a
feature such as the one discussed in this thread would help them greatly in
getting better code coverage numbers.
Che
You hit the nail right on the head Jochen wrt synthetic methods. And as you
correctly pointed out, not all transformations need to be updated right
away. I wanted to lay out a set of tasks we must take into consideration
should this feature be accepted.
Cheers,
Andres
On 08.09.2017 15:04, Andres Almiray wrote:
Unfortunately that annotation is coming in JDK9. We'll need something
that can be used with JDK7
actually that would not be a problem. If the annotation is not found it
is ignored by the java compiler. The source retention policy though is a
very goo
On 08.09.2017 11:55, Cédric Champeau wrote:
I'm not super keen on adding a "feature" like that. First, we already
mark generated methods, thanks to the "synthetic" modifier that fields,
methods and classes can have.
synthetic means for an IDE to not to show that method. That may not be
right
uot;
> *Envoyé: *Vendredi 8 Septembre 2017 15:03:05
> *Objet: *Re: Groovy and code coverage
>
> Damn, who thought it was a good idea to put TIMESTAMPS in generated
> sources?
>
>
> It's a drop in replacement for javax.annotation.Generated [1] which is in
> a module
> De: "Cédric Champeau"
> À: "dev"
> Envoyé: Vendredi 8 Septembre 2017 15:03:05
> Objet: Re: Groovy and code coverage
> Damn, who thought it was a good idea to put TIMESTAMPS in generated sources?
It's a drop in replacement for javax.annotation.Generate
You are generating bytecode ?
Rémi
> De: "Andres Almiray"
> À: "dev"
> Envoyé: Vendredi 8 Septembre 2017 15:04:57
> Objet: Re: Groovy and code coverage
> Unfortunately that annotation is coming in JDK9. We'll need something t
ava 9:
> http://download.java.net/java/jdk9/docs/api/javax/annotation/processing/
> Generated.html
>
> Rémi
>
> --
>
> *De: *"Andres Almiray"
> *À: *[email protected]
> *Envoyé: *Vendredi 8 Septembre 2017 11:41:18
> *Objet: *Groovy
>
> Rémi
>
> --
>
> *De: *"Andres Almiray"
> *À: *[email protected]
> *Envoyé: *Vendredi 8 Septembre 2017 11:41:18
> *Objet: *Groovy and code coverage
>
> Hello everyone,
>
> As you may be aware there are only a few choices in
A standard annotation for generated code was added in Java 9:
http://download.java.net/java/jdk9/docs/api/javax/annotation/processing/Generated.html
Rémi
> De: "Andres Almiray"
> À: [email protected]
> Envoyé: Vendredi 8 Septembre 2017 11:41:18
> Objet: Groovy and
I'm not super keen on adding a "feature" like that. First, we already mark
generated methods, thanks to the "synthetic" modifier that fields, methods
and classes can have. Second, either we would have to change the code of
all AST transformations to add this at the relevant places, or
automatically
Hello everyone,
As you may be aware there are only a few choices in the Java pace that can
be used for code coverage, JaCoCo being the one that gives the most
accurate results. While it's easy to setup JaCoco for Groovy sources there
are times where the tool reports no coverage for some lines of c
14 matches
Mail list logo
