Ive получил проект от среднего до крупного масштаба с ~ 150 000 LOC. Jacoco maven-plugin генерирует отчеты по каждому модульному тесту в файл jacoco.exec.SonarQube Java :: JaCoCo Слушатели генерируют огромный отчет jacoco.exec
Таким образом, в основном это безошибочный установка в pom.xml:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version>2.17</version>
<configuration>
<argLine>-XX:-UseSplitVerifier</argLine>
<includes>
<include>**/*Test.java</include>
<include>**/*Tests.java</include>
</includes>
<excludes>
<exclude>**/it/*IT.java</exclude>
<exclude>**/*IT.java</exclude>
</excludes>
<properties>
<property>
<name>listener</name>
<value>org.sonar.java.jacoco.JUnitListener</value>
</property>
</properties>
</configuration>
</plugin>
<plugin>
Хитрость будучи JUnitListener. Целевой файл jacoco.exec достигает 4,5 ГБ (огромный!). Когда наши подчиненные Jenkins CI начнут обрабатывать файл, сонар-бегун (артефакт maven) также пытается загрузить весь файл в память - или так кажется. И для этого требуется размер кучи 8 гигов. Это кажется совершенно неправильным, не так ли?
Вопрос здесь, можно ли что-либо сделать, чтобы свести к минимуму размер jacoco.exec? Мы ограничены Java 1.6 SDK (заметили, что размер стал < 2 Gb с Java 1.7). Я предполагаю, что символы отладки - это необходимость в создании отчета о покрытии, или я ошибаюсь?
Да, требуется отладка во время компиляции. Hm Я никогда не видел .exec-файла, идущего более чем на несколько МБ. –
Ключом к размеру файла .exec является наш профиль «охват за тест». Я вставил раздел '' выше с дополнительным отступом. Мониторинг размера файлов во время тестовой фазы (junit) указывает, что дамп состояния VM вводится для каждого теста. И я читал, он делится на успех/неудачно - но это все, что я про процесс знаю в основном –
mschr
* bump * none не имеет опыта работы с этой проблемой? – mschr