maven findbugs «высокая отметка» - PullRequest
3 голосов
/ 25 июня 2010

[findbugs является примером здесь, вопрос применим к любому такому плагину maven]

Я недавно посетил лекцию по сборке, и мне очень понравился шаблон, о котором мне очень понравилось: при добавлении нового инструмента в цепочку, когда вы начинаете с n нарушений, вы должны продолжать уменьшать n (высокая отметка) и сбой сборки только тогда, когда текущая проверка превышает последнее значение n.

findbugs только что были добавлены в нашу сборку, и мы искали способ реализовать этот шаблон. Мы не могли найти никакого способа сделать это с помощью конфигурации плагина, поэтому было любопытно, если бы кто-нибудь там мог упомянуть, как они достигли этого. Полагаю, очевидным способом является настройка плагина, но прежде чем мы начнем заряжаться, хотелось бы услышать мысли других.

Ответы [ 4 ]

2 голосов
/ 25 июня 2010

Случай FindBugs, на мой взгляд, несколько специфичен: нарушения не просто косметические, они могут быть реальными ошибками и поэтому должны быть исправлены, по крайней мере, с ошибками высокого приоритета (т.е. при использовании порога High).

На всякий случай, мы следуем аналогичной схеме (наше определение done включает отсутствие увеличения технического долга ), но мы не реализовали его в Maven (и мы не провалили сборку),Мы используем сонар и его машину времени для отслеживания эволюции метрик (мы отслеживаем ежедневную эволюцию).Он хорошо работает для нас, даже если он не так силен, как сбой сборки.

2 голосов
/ 25 июня 2010

Findbugs (и все другие плагины метрик кода, о которых я знаю) генерирует файл XML . Я хотел бы написать плагин Maven, который специализируется на чтении этих XML-файлов. Он будет хранить частную справочную таблицу где-нибудь, где хранит данные для каждой сборки, для последних значений метрики.

Он будет использовать общий интерфейс синтаксического анализатора, который вы должны будете реализовать для каждого плагина метрики. Конфиг будет примерно таким:

<plugin>
    <groupId>com.yourcompany</groupId>
            <artifactId>your-plugin-id</artifactId>
            <version>1.0</version>
            <executions>
                    <execution>
                        <id>readmetrics</id>
                        <phase>process-classes</phase>
                        <goals>
                            <goal>analyse-metrics</goal>
                        </goals>
                    </execution>
             </executions>
             <configuration>
                  <metrics>
                      <metric>
                          <type>findbugs</type>
                          <file>${project.reporting.outputDirectory}/findbugs/output.xml</file>
                      </metric>
                      <metric>
                          <type>checkstyle</type>
                          <file>${project.reporting.outputDirectory}/checkstyle/output.xml</file>
                      </metric>
                      <metric>
                          <type>pmd</type>
                          <file>${project.reporting.outputDirectory}/pmd/output.xml</file>
                      </metric>
                  </metrics>
              </configuration>
        </plugin>
1 голос
/ 30 июня 2010

Я поднял эту проблему в трекере findbugs maven (см. http://jira.codehaus.org/browse/MFINDBUGS-115).

Кроме того, в качестве части этого кода я написал патч. Мы успешно используем этот патч в нашем большом многомодульном проекте.

Вы можете либо синхронизировать код и применить исправление, следуя инструкциям на сайте плагина findbugs-maven-plugin, либо, возможно, исправление или его производная могут быть приняты в какой-либо будущей версии плагина.

0 голосов
/ 05 июля 2010

Забавно, что вы упомянули об этом, потому что сейчас я работаю именно над этим для своего работодателя.Мы выделили проект с открытым исходным кодом для хранения работы под названием dybdob ;поскольку очень находится в стадии разработки, код, который сейчас находится в репо, довольно ужасен и очень жестко запрограммирован / хакерский.Тем не менее, план состоит в том, чтобы сделать более или менее точно то, что предлагает seanizer: проанализировать XML, сохранить счетчики и потерпеть неудачу, если их увеличить.

Первое, что я реализовал (опять же: жестко закодировано, взломано и недокументировано) - это плагин, который фактически подсчитывает предупреждения компилятора javac, выходящие из сборки, и прерывает сборку, если эта сумма увеличивается.Это сейчас работает, и в настоящее время я параллельно работаю над предупреждениями findbugs, checkstyle и pmd.

Хотел бы, чтобы вы проверили это, и напишите мне, если вы хотите помочь (или даже просто хочу посмотреть, как оно развивается).

...