Extract "validation" tests into separate modules #711

Godin · 2018-07-14T22:47:26Z

Defaults

module org.jacoco.core.test.validation.java5 now contains what previously was in org.jacoco.core.test/src/org/jacoco/core/test/(validation|filter)
module org.jacoco.core.test.validation.java7 what previously was in org.jacoco.core.test/src-java7
module org.jacoco.core.test.validation.java8 what previously was in org.jacoco.core.test/src-java8

Previously manual configuration was needed for inclusion of the last two sources into build and to open them in IntelliJ IDEA. Now by default all modules included into build and so showup in IntelliJ IDEA.

By default the last two will be compiled into bytecode version 51 (Java 7) and 52 (Java 8) respectively, all other into 49 (Java 5).

And build is simple as

$ java -version
java version "1.8.0_172"
Java(TM) SE Runtime Environment (build 1.8.0_172-b11)
Java HotSpot(TM) 64-Bit Server VM (build 25.172-b11, mixed mode)

$ mvn clean verify
...
[INFO] Reactor Build Order:
...
[INFO] JaCoCo :: Test :: Core                                             [jar]
[INFO] JaCoCo :: Test :: Core :: Validation                               [pom]
[INFO] JaCoCo :: Test :: Core :: Validation Java 5                        [jar]
[INFO] JaCoCo :: Test :: Core :: Validation Java 7                        [jar]
[INFO] JaCoCo :: Test :: Core :: Validation Java 8                        [jar]
[INFO] JaCoCo :: Test :: Report                                           [jar]
...

$ javap -v org.jacoco.core/target/classes/org/jacoco/core/JaCoCo.class | grep major
  major version: 49

$ javap -v org.jacoco.core.test.java7/target/classes/org/jacoco/core/test/filter/TryWithResourcesTest.class | grep major
  major version: 51

$ javap -v org.jacoco.core.test.java8/target/classes/org/jacoco/core/test/validation/LambdaExpressionsTest.class | grep major
  major version: 52

Should be noted that JDKs 9 - 12 can't compile into bytecode versions lower than 50 (Java 6) - see JEP-182. So when they are used modules org.jacoco.core.test.java7 and org.jacoco.core.test.java8 will be compiled as above, however all other modules will be compiled into bytecode version 50 (Java 6):

$ java -version
openjdk version "9.0.4"
OpenJDK Runtime Environment (build 9.0.4+11)
OpenJDK 64-Bit Server VM (build 9.0.4+11, mixed mode)

$ mvn clean verify
...
[INFO] Reactor Build Order:
...
[INFO] JaCoCo :: Test :: Core                                             [jar]
[INFO] JaCoCo :: Test :: Core :: Validation                               [pom]
[INFO] JaCoCo :: Test :: Core :: Validation Java 5                        [jar]
[INFO] JaCoCo :: Test :: Core :: Validation Java 7                        [jar]
[INFO] JaCoCo :: Test :: Core :: Validation Java 8                        [jar]
[INFO] JaCoCo :: Test :: Report                                           [jar]
...

$ javap -v org.jacoco.core/target/classes/org/jacoco/core/JaCoCo.class | grep major
  major version: 50

$ javap -v org.jacoco.core.test.java7/target/classes/org/jacoco/core/test/filter/TryWithResourcesTest.class | grep major
  major version: 51

$ javap -v org.jacoco.core.test.java8/target/classes/org/jacoco/core/test/validation/LambdaExpressionsTest.class | grep major
  major version: 52

And JDK 12 soon will stop compiling into bytecode versions lower than 51 (Java 7) - see JDK-8028563, from which seems that change will be in build right after EA b2 (jdk-12+2) that is currently available.

Previously manual configuration was required to do build with JDK version greater than 8.

Also could be noted that builds with JDK greater than 10 still fail with the same reasons as before, which are unrelated to these changes.

Property `jdk.version`

Property jdk.version can be specified to compile and run tests using JDK that is different from current.

As before location of JDK will be selected from Maven toolchains.xml with respective value of version tag, however now values do not have 1. prefix.

As before JDK 5 will be used for snapshots and releases.

When value of this property is 5, 6, 7 or 8, defaults are the same as described above for JDK 8,
when value is 9, 10, 11 or 12, defaults are the same as described above for JDKs 9 - 12:

$ java -version
java version "1.8.0_172"
Java(TM) SE Runtime Environment (build 1.8.0_172-b11)
Java HotSpot(TM) 64-Bit Server VM (build 25.172-b11, mixed mode)

$ mvn clean verify -Djdk.version=9
...
[INFO] Reactor Build Order:
...
[INFO] JaCoCo :: Test :: Core                                             [jar]
[INFO] JaCoCo :: Test :: Core :: Validation                               [pom]
[INFO] JaCoCo :: Test :: Core :: Validation Java 5                        [jar]
[INFO] JaCoCo :: Test :: Core :: Validation Java 7                        [jar]
[INFO] JaCoCo :: Test :: Core :: Validation Java 8                        [jar]
[INFO] JaCoCo :: Test :: Report                                           [jar]
...
[INFO] Toolchain (jdk) matched:JDK[/home/godin/.java-select/versions/9]
...
[INFO] Toolchain in compiler-plugin: JDK[/home/godin/.java-select/versions/9]
...
[INFO] Toolchain in maven-javadoc-plugin: JDK[/home/godin/.java-select/versions/9]
...
[INFO] Toolchain in surefire-plugin: JDK[/home/godin/.java-select/versions/9]
...

$ javap -v org.jacoco.core/target/classes/org/jacoco/core/JaCoCo.class | grep major
  major version: 50

$ javap -v org.jacoco.core.test.java7/target/classes/org/jacoco/core/test/filter/TryWithResourcesTest.class | grep major
  major version: 51

$ javap -v org.jacoco.core.test.java8/target/classes/org/jacoco/core/test/validation/LambdaExpressionsTest.class | grep major
  major version: 52

Additionally, when value of this property is 5 or 6, modules org.jacoco.core.test.java7 and org.jacoco.core.test.java8 will be excluded:

$ java -version
java version "1.8.0_172"
Java(TM) SE Runtime Environment (build 1.8.0_172-b11)
Java HotSpot(TM) 64-Bit Server VM (build 25.172-b11, mixed mode)

$ mvn clean verify -Djdk.version=5
...
[INFO] Reactor Build Order:
...
[INFO] JaCoCo :: Test :: Core                                             [jar]
[INFO] JaCoCo :: Test :: Core :: Validation                               [pom]
[INFO] JaCoCo :: Test :: Core :: Validation Java 5                        [jar]
[INFO] JaCoCo :: Test :: Report                                           [jar]
...
[INFO] Toolchain (jdk) matched:JDK[/home/godin/.java-select/versions/5]
...
[INFO] Toolchain in compiler-plugin: JDK[/home/godin.mandrikov/.java-select/versions/5]
...
[INFO] Toolchain in maven-javadoc-plugin: JDK[/home/godin/.java-select/versions/5]
...
[INFO] Toolchain in surefire-plugin: JDK[/home/godin/.java-select/versions/5]
...

When value is 7, module org.jacoco.core.test.java8 will be excluded:

$ mvn clean verify -Djdk.version=7
...
Java version: 1.8.0_172, vendor: Oracle Corporation
Java home: /home/godin/.java-select/versions/8
...
[INFO] Reactor Build Order:
...
[INFO] JaCoCo :: Test :: Core                                             [jar]
[INFO] JaCoCo :: Test :: Core :: Validation                               [pom]
[INFO] JaCoCo :: Test :: Core :: Validation Java 5                        [jar]
[INFO] JaCoCo :: Test :: Core :: Validation Java 7                        [jar]
[INFO] JaCoCo :: Test :: Report                                           [jar]
...
[INFO] Toolchain (jdk) matched:JDK[/home/godin/.java-select/versions/7]
...
[INFO] Toolchain in compiler-plugin: JDK[/home/godin/.java-select/versions/7]
...
[INFO] Toolchain in maven-javadoc-plugin: JDK[/home/godin/.java-select/versions/7]
...
[INFO] Toolchain in surefire-plugin: JDK[/home/godin/.java-select/versions/7]
...

$ javap -v org.jacoco.core/target/classes/org/jacoco/core/JaCoCo.class | grep major
  major version: 49

$ javap -v org.jacoco.core.test.java7/target/classes/org/jacoco/core/test/filter/TryWithResourcesTest.class | grep major
  major version: 51

Property `bytecode.version`

Property bytecode.version can be specified to compile modules into bytecode version different from their defaults described above.

Now values of this property should not have 1. prefix.

Modules org.jacoco.core.test.java7 and org.jacoco.core.test.java8 will be excluded when value of this property is 5 or 6:

$ mvn clean verify -Dbytecode.version=6
...
[INFO] Reactor Build Order:
...
[INFO] JaCoCo :: Test :: Core                                             [jar]
[INFO] JaCoCo :: Test :: Core :: Validation                               [pom]
[INFO] JaCoCo :: Test :: Core :: Validation Java 5                        [jar]
[INFO] JaCoCo :: Test :: Report                                           [jar]
...

$ javap -v org.jacoco.core/target/classes/org/jacoco/core/JaCoCo.class | grep major
  major version: 50

Module org.jacoco.core.test.java8 will be excluded when value of this property is 7:

$ mvn clean verify -Dbytecode.version=7
...
[INFO] Reactor Build Order:
...
[INFO] JaCoCo :: Test :: Core                                             [jar]
[INFO] JaCoCo :: Test :: Core :: Validation                               [pom]
[INFO] JaCoCo :: Test :: Core :: Validation Java 5                        [jar]
[INFO] JaCoCo :: Test :: Core :: Validation Java 7                        [jar]
[INFO] JaCoCo :: Test :: Report                                           [jar]
...

$ javap -v org.jacoco.core/target/classes/org/jacoco/core/JaCoCo.class | grep major
  major version: 51

Additionally, it can be combined with property jdk.version:

$ mvn clean verify -Dbytecode.version=5 -Djdk.version=9
...
[ERROR] error: Source option 1.5 is no longer supported. Use 1.6 or later.
[ERROR] error: Target option 1.5 is no longer supported. Use 1.6 or later.
...

Also should be noted that maven-shade-plugin and maven-plugin-plugin can't process bytecode versions 54 (Java 10), 55 (Java 11) and 56 (Java 12). So when value of this property is 10, 11 or 12, only test modules (org.jacoco.*.test.*) will be compiled into specified bytecode version and others will be compiled into 53 (Java 9):

$ java -version
openjdk version "12-ea" 2019-03-19
OpenJDK Runtime Environment 19.3 (build 12-ea+2)
OpenJDK 64-Bit Server VM 19.3 (build 12-ea+2, mixed mode)

$ mvn clean verify -Dbytecode.version=10

$ javap -v org.jacoco.core/target/classes/org/jacoco/core/JaCoCo.class | grep major
  major version: 53

$ javap -v org.jacoco.core.test/target/classes/org/jacoco/core/JaCoCoTest.class | grep major
  major version: 54

$ java -version
openjdk version "12-ea" 2019-03-19
OpenJDK Runtime Environment 19.3 (build 12-ea+2)
OpenJDK 64-Bit Server VM 19.3 (build 12-ea+2, mixed mode)

$ mvn clean verify -Dbytecode.version=11

$ javap -v org.jacoco.core/target/classes/org/jacoco/core/JaCoCo.class | grep major
  major version: 53

$ javap -v org.jacoco.core.test/target/classes/org/jacoco/core/JaCoCoTest.class | grep major
  major version: 55

$ java -version
openjdk version "12-ea" 2019-03-19
OpenJDK Runtime Environment 19.3 (build 12-ea+2)
OpenJDK 64-Bit Server VM 19.3 (build 12-ea+2, mixed mode)

$ mvn clean verify -Dbytecode.version=12

$ javap -v org.jacoco.core/target/classes/org/jacoco/core/JaCoCo.class | grep major
  major version: 53

$ javap -v org.jacoco.core.test/target/classes/org/jacoco/core/JaCoCoTest.class | grep major
  major version: 56

Property `ecj`

Property ecj can be specified to compile all modules using ECJ.

For the time being with ECJ we compile all modules into bytecode version 52 (Java 8) unconditionally (and we were testing only this configuration in Travis even before these changes), however it can be combined with properties bytecode.version and jdk.version for selection of modules and JDK for execution of tests:

$ java -version
java version "1.8.0_152"
Java(TM) SE Runtime Environment (build 1.8.0_152-b16)
Java HotSpot(TM) 64-Bit Server VM (build 25.152-b16, mixed mode)

$ mvn clean verify -Decj -Dbytecode.version=7 -Djdk.version=9
...
[INFO] Reactor Build Order:
...
[INFO] JaCoCo :: Test :: Core                                             [jar]
[INFO] JaCoCo :: Test :: Core :: Validation                               [pom]
[INFO] JaCoCo :: Test :: Core :: Validation Java 5                        [jar]
[INFO] JaCoCo :: Test :: Core :: Validation Java 7                        [jar]
[INFO] JaCoCo :: Test :: Report                                           [jar]
...
[INFO] Toolchain (jdk) matched:JDK[/home/godin/.java-select/versions/9]
...
[INFO] Toolchain in compiler-plugin: JDK[/home/godin/.java-select/versions/9]
...
[INFO] Toolchain in maven-javadoc-plugin: JDK[/home/godin/.java-select/versions/9]
...
[INFO] Toolchain in surefire-plugin: JDK[/home/godin/.java-select/versions/9]
...

$ javap -v org.jacoco.core/target/classes/org/jacoco/core/JaCoCo.class | grep major
  major version: 52

$ javap -v org.jacoco.core.test/target/classes/org/jacoco/core/JaCoCoTest.class | grep major
  major version: 52

$ javap -v org.jacoco.core.test.java8/target/classes/org/jacoco/core/test/validation/LambdaExpressionsTest.class | grep major
  major version: 52

Godin · 2018-07-14T23:33:16Z

@marchof could you please have a look on these changes? if all fine, I will also update documentation.

As expected individual profiles are now shorter (#709 (comment)), but there are anyway some duplication in pom.xmls (#709 (comment)) as a necessary evil to have good defaults and customizations. This solves quite some headaches that I had during testing of different JDKs and filters.

marchof · 2018-07-16T06:05:38Z

@Godin Thanks for taking up this effort!

I wonder how the dependencies should look like: Currently the base infrastructure is part of module org.jacoco.core.test.java5 (like Source). This would mean that e.g. Kotlin will have a dependency on org.jacoco.core.test.java5. I would prefer to move all common infraststructure to org.jacoco.core.test. Some tests can then be extended. E.g. FramesTest should get a common abstract base class. Then we can also do tests on Java7 and so on. But I can work on this in a separate PR.

Godin · 2018-07-16T19:48:35Z

@marchof

I would prefer to move all common infraststructure to org.jacoco.core.test.

Good point - done.

Some tests can then be extended. E.g. FramesTest should get a common abstract base class. Then we can also do tests on Java7 and so on.

You mean to run FramesTest on targets from java7 module?

But I can work on this in a separate PR.

Indeed will be better to do after this PR in order to unblock addition of tests for Kotlin.

I added update for documentation, so could you please do re-review?

marchof · 2018-07-16T20:00:40Z

@Godin Thanks for fixing dependencies!

You mean to run FramesTest on targets from java7 module?

This is what I wanted to propose. Separate PR fine to me as this would be a new feature anyways.

marchof

Hi @Godin I added some questions to the change set.

marchof · 2018-07-16T20:03:16Z

org.jacoco.build/pom.xml

@@ -708,37 +709,67 @@
      </build>
    </profile>

-    <!-- This profile is used to launch tests with compilation into specific bytecode version. -->
+    <!-- -->


Is this empty comment on purpose?

Yep - for visual separation of profile that follows this comment from one that is above.

Some profiles are separated but some are not. I assume these are groups of profiles, right? Maybe add a short description into the comment for the profile group like with the profiles at the top?

I added comments.

marchof · 2018-07-16T20:03:48Z

org.jacoco.build/pom.xml

@@ -776,12 +809,14 @@
      </build>
    </profile>

+    <!-- -->


Empty comment?

Yep - for visual separation of profiles that follow this comment from ones that are above.

marchof · 2018-07-16T20:04:16Z

org.jacoco.core.test.java7/pom.xml

+
+  <artifactId>org.jacoco.core.test.java7</artifactId>
+
+  <!--<name></name>-->


Commented tag? Remove?

I was wondering if we want to assign name for consistency with the rest? If omitted, then name is assumed to be equal to artifactId and here is how it looks currently:

... [INFO] JaCoCo :: Test :: Core [jar] [INFO] org.jacoco.core.test.java5 [jar] ... [INFO] JaCoCo :: Test :: Core ............................. SUCCESS [ 0.039 s] [INFO] org.jacoco.core.test.java5 ......................... SUCCESS [ 0.021 s] ...

Right, then the new modules should also have proper names. What about this?

JaCoCo :: Test :: Core :: Integration Java 5

marchof · 2018-07-16T20:07:05Z

org.jacoco.core.test.java7/pom.xml

+  <!--<name></name>-->
+
+  <properties>
+    <jacoco.includes>org.jacoco.core.*</jacoco.includes>


I would prefer to not record coverage for integration tests at all. In this case this property is not relevant.

They are not included into final report.

All classes are included into instrumentation and agent is enabled by default - see

jacoco/org.jacoco.tests/pom.xml

Lines 49 to 70 in 753d653

<plugin>

<groupId>org.jacoco</groupId>

<artifactId>jacoco-maven-plugin</artifactId>

<version>${project.version}</version>

<configuration>

<exclClassLoaders>sun.reflect.DelegatingClassLoader:org.jacoco.core.test.TargetLoader:org.jacoco.core.test.InstrumentingLoader</exclClassLoaders>

<sessionId>${project.artifactId}</sessionId>

<includes>

<include>${jacoco.includes}</include>

</includes>

<excludes>

<exclude>${jacoco.excludes}</exclude>

</excludes>

</configuration>

<executions>

<execution>

<goals>

<goal>prepare-agent</goal>

</goals>

</execution>

</executions>

</plugin>

Thus if we want to exclude all classes from instrumentation, then this should be replaced by jacoco.excludes? Or if we want to completely disable agent, then jacoco.skip?

Yep, I think JaCoCo agent should not be in the game for integration tests. Targets are instrumented programmatically anyways during the test. So jacoco.skip would be the best fit here (and jacoco.includes can be removed at all).

Replaced jacoco.includes by jacoco.skip.

marchof · 2018-07-16T20:08:31Z

org.jacoco.tests/pom.xml

    <module>../org.jacoco.report.test</module>
    <module>../org.jacoco.agent.rt.test</module>
    <module>../org.jacoco.agent.test</module>
    <module>../org.jacoco.ant.test</module>
    <module>../org.jacoco.cli.test</module>
-    <module>../org.jacoco.examples.test</module>


Why do we need to move these tests?

Because otherwise they will be executed before modules from profiles.

Sorry for my stupid question: And why would this be a problem?

Because org.jacoco.examples.test and especially jacoco-maven-plugin.test are the slowest ones, while perform tests on a way higher level than org.jacoco.core.test.*.

So you mean like "fail fast"? Where is that important? For local develop/test iterations I mostly run specific modules only anyways. For our CI all tests are executed anyways.

I just find it rather confusing that these modules are now included in specific JDK profiles.

Re module names: For consistency we should also adjust Java package names to the new module names.

I added org.jacoco.core.test.validation as parent for org.jacoco.core.test.validation.*

Not sure that I like that amount of folders in root. Maybe later we can think of grouping like for example

validation |- pom.xml |- java5 | \- pom.xml |- java7 | \- pom.xml \- java8 \- pom.xml

Absolutely! The same for the unit tests. We could simplify the structure if we could move to a more Maven standard project layout. But again... separate issue.

We could simplify the structure if we could move to a more Maven standard project layout.

In truly standard Maven layout, unit tests are located in the same module as main code, but we can't do this because we need to execute JaCoCo for JaCoCo itself - see #312 (comment)

I know 😉

marchof · 2018-07-16T20:11:33Z

@Godin Do we still need the constructor ValidationTestBase(final String srcFolder, final Class<?> target)?

marchof · 2018-07-16T20:12:26Z

@Godin Can we add Eclipse configs to the new projects? At least as "plain project" so it can be easily imported.

Godin · 2018-07-16T20:58:05Z

Do we still need the constructor ValidationTestBase(final String srcFolder, final Class<?> target)?

Removed.

Godin · 2018-07-16T21:20:40Z

Can we add Eclipse configs to the new projects? At least as "plain project" so it can be easily imported.

@marchof you know that for Java development I mostly use IntelliJ IDEA and nowadays don't use even it, because mostly do development in C++ 😉

I added files, hopefully with correctly linked settings and correctly specified JRE. Could you please check import into IDE?

marchof · 2018-07-16T21:37:44Z

@Godin Thanks for the Eclipse settings! I can now import but not compile because the shared settings declare org.eclipse.jdt.core.compiler.compliance=1.5. But we can sort this out separately (Eclipse setup is somewhat broken anyways).

Godin · 2018-07-16T21:44:17Z

@marchof about import into Eclipse IDE - I was thinking about Oomph

marchof · 2018-07-16T21:45:32Z

org.jacoco.doc/docroot/doc/build.html

 &lt;/toolchains&gt;
 </pre>

 <p>
-  Now you should be able to execute maven build with specified version of JDK:
+  to execute compilation and tests using JDK 5 or 6:


Shouldn't that be moved after the next section ("Location of toolchains.xml ...")?

Also should start with upper case: "To execute ..."

Here is how this currently looks/reads to me:

You can set property jdk.version to use JDK specified in Maven Toolchains with respective value of version tag. For example you can create following ~/.m2/toolchains.xml file
...
to execute compilation and tests using JDK 5 or 6:

mvn clean install -Djdk.version=5 mvn clean install -Djdk.version=6

Notice that above we refer to default location of toolchains.xml, after that show that non-default can be specified:

Location of toolchains.xml can be set via an option:

mvn --toolchains path clean install -Djdk.version=version

So for me the page currently has the following structure

Information about toolchain

Information how to run the build for specific JDK versions

Information about toolchain

Information how to run the build for specific JDK versions

Or do we need a separate toolchain.xml for step 4? The this should be noted.

marchof · 2018-07-16T21:47:31Z

@Godin Oomph might be helpful here. But let's fix this separate from this PR.

marchof · 2018-07-16T21:51:55Z

org.jacoco.core.test.validation.java5/.project

@@ -0,0 +1,30 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<projectDescription>
+	<name>org.jacoco.core.test.java5</name>


Should now read org.jacoco.core.test.validation.java5. Same issue with the other new org.jacoco.core.test.validation.* projects.

Godin · 2018-07-16T22:24:25Z

@marchof

Re module names: For consistency we should also adjust Java package names to the new module names.

Before/Currently packages org.jacoco.core.test.filter and org.jacoco.core.test.filter.targets are present in java5 and java7 modules, and packages org.jacoco.core.test.validation and org.jacoco.core.test.validation.targets are present in java5 and java8 modules. So how would you like to organize packages?

marchof · 2018-07-16T22:56:43Z

@Godin Regarding package naming: Probably it doesn't make sense any more to distinguish between "filter" and "non filter" as validation tests should verify the overall functionality in respect to different language feature. Therefore I would propose to use two packages only per module:

org.jacoco.core.test.validation.xxx
org.jacoco.core.test.validation.xxx.targets

Side note: Some tests should probably be moved to org.jacoco.core.test module (like ResizeInstructionsTest). But again: Separate PR.

marchof

The updated documentations is great! Let's merge now.

I'll work on separate PRs to organize test code package names.

Godin added type: enhancement component: build labels Jul 14, 2018

Godin added this to the 0.8.2 milestone Jul 14, 2018

Godin self-assigned this Jul 14, 2018

Godin requested a review from marchof July 14, 2018 23:33

Godin force-pushed the separate-validation-tests branch 2 times, most recently from 907f14b to 0be0b88 Compare July 14, 2018 23:41

Godin added the component: test label Jul 14, 2018

Godin force-pushed the separate-validation-tests branch 8 times, most recently from 7c774cd to 62e98e8 Compare July 16, 2018 19:21

(WIP)

8b3cd7f

Godin force-pushed the separate-validation-tests branch from 62e98e8 to 8b3cd7f Compare July 16, 2018 19:33

marchof requested changes Jul 16, 2018

View reviewed changes

Godin added 3 commits July 16, 2018 22:51

set names

e641dd3

jacoco.skip

003d4b6

remove unused constructor

00fedf3

Add files for Eclipse IDE

9a1bd19

add comment into example of toolchains.xml

eca9851

marchof reviewed Jul 16, 2018

View reviewed changes

Godin force-pushed the separate-validation-tests branch from 6fed97f to 0905d24 Compare July 16, 2018 21:54

Godin force-pushed the separate-validation-tests branch from 53488f7 to efa8e21 Compare July 16, 2018 22:33

org.jacoco.core.test.validation

126b6f9

Godin force-pushed the separate-validation-tests branch from efa8e21 to 36ef13f Compare July 16, 2018 22:47

Godin force-pushed the separate-validation-tests branch 4 times, most recently from 6d79b09 to 33a5636 Compare July 20, 2018 19:01

comments in org.jacoco.build/pom.xml

1621a70

Godin force-pushed the separate-validation-tests branch 3 times, most recently from d12f993 to f5cf359 Compare July 20, 2018 20:03

tweak documentation

f5cf359

marchof approved these changes Jul 21, 2018

View reviewed changes

update changelog

13fcd52

Godin merged commit 88e67b3 into master Jul 21, 2018

Godin deleted the separate-validation-tests branch July 21, 2018 20:47

Godin mentioned this pull request Aug 3, 2018

Add module for Kotlin validation tests #720

Merged

fabianishere mentioned this pull request Aug 10, 2018

Add validation tests for Kotlin lateinit properties and data classes #709

Merged

marchof mentioned this pull request Aug 20, 2018

Create separate modules for core integration tests #506

Closed

jacoco locked as resolved and limited conversation to collaborators Oct 8, 2018


		<artifactId>org.jacoco.core.test.java7</artifactId>

		<!--<name></name>-->

	<plugin>
	<groupId>org.jacoco</groupId>
	<artifactId>jacoco-maven-plugin</artifactId>
	<version>${project.version}</version>
	<configuration>
	<exclClassLoaders>sun.reflect.DelegatingClassLoader:org.jacoco.core.test.TargetLoader:org.jacoco.core.test.InstrumentingLoader</exclClassLoaders>
	<sessionId>${project.artifactId}</sessionId>
	<includes>
	<include>${jacoco.includes}</include>
	</includes>
	<excludes>
	<exclude>${jacoco.excludes}</exclude>
	</excludes>
	</configuration>
	<executions>
	<execution>
	<goals>
	<goal>prepare-agent</goal>
	</goals>
	</execution>
	</executions>
	</plugin>

Extract "validation" tests into separate modules #711

Extract "validation" tests into separate modules #711

Conversation

Godin commented Jul 14, 2018 • edited Loading

Defaults

Property jdk.version

Property bytecode.version

Property ecj

Godin commented Jul 14, 2018

marchof commented Jul 16, 2018 • edited by Godin Loading

Godin commented Jul 16, 2018

marchof commented Jul 16, 2018 • edited Loading

marchof left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

marchof commented Jul 16, 2018

marchof commented Jul 16, 2018

Godin commented Jul 16, 2018

Godin commented Jul 16, 2018

marchof commented Jul 16, 2018

Godin commented Jul 16, 2018

Choose a reason for hiding this comment

Godin Jul 16, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

marchof commented Jul 16, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Godin commented Jul 16, 2018

marchof commented Jul 16, 2018

marchof left a comment

Choose a reason for hiding this comment

Godin commented Jul 14, 2018 •

edited

Loading

Property `jdk.version`

Property `bytecode.version`

Property `ecj`

marchof commented Jul 16, 2018 •

edited by Godin

Loading

marchof commented Jul 16, 2018 •

edited

Loading

Godin Jul 16, 2018 •

edited

Loading