Category: Программы и инструменты

[Заметка] Статический анализ кода на Java: Sonar и Maven

Вкратце о том как подключить Sonar к вашему проекту на Maven.
Чтобы ваш проект попал в сонар по дефолту достаточно просто выполнить команду

mvn sonar:sonar

Проблема в том что для выполнения этой команды сонару нужно знать дополнительно несколько вещей, а именно:

  • Язык вашего проекта: sonar.language
  • Адрес сайта сонара: sonar.host.url
  • Настройки БД сонара: sonar.jdbc.url, sonar.jdbc.driver, sonar.jdbc.username,sonar.jdbc.password

Язык вашего проекта и адрес сайта это публичная информация и указываем их прямо в pom.xml файле:

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
...
    <properties>
        <sonar.language>java</sonar.language>
        <sonar.host.url>http://sonar.example.com:9000/</sonar.host.url>
    </properties>
...
</project>

Настройки БД не должны быть видны народу поэтому мы устанавливаем их в settings.xml

<profile>
   <id>sonar</id>
   <activation>
      <activeByDefault>true</activeByDefault>
   </activation>
   <properties>
      <sonar.jdbc.url>jdbc:postgresql://localhost/sonar</sonar.jdbc.url>
      <sonar.jdbc.driver>org.postgresql.Driver</sonar.jdbc.driver>
      <sonar.jdbc.username>user</sonar.jdbc.username>
      <sonar.jdbc.password>password</sonar.jdbc.password>
   </properties>
</profile>

После этого запускаем
mvn sonar:sonar
Ещё годная статья по теме

Реклама

Why do I hate Maven?

Мавен упорно позиционирует себя как билд тул, хотя на самом деле он ни что иное как менеджер пакетов и конфигураций.
Т.е. через мавен я не могу через мавен ставить например ява пакеты как программы, а не как библиотеки.
Не могу например grails или какой нибудь sdk скачать и установить.
Когда я работаю с мавеном у меня постоянно всплывают воспоминания и дебиановском пакетном менеджере.
Мавену явно нужно было брать с ниго пример, там очень много крутых вещей в документации таится о которой не все линуксоиды знают (я помню меня сильно впечатлил строгость формата changelog файла).

Во вторых мне не нравится что мавен является не эволюционным продолжением анта, а конкурирующим с ним продуктом.
В итоге нельзя эволюциооно обновлять свой антовский проект — только сразу на мавен, только хардкор. Для слабоков смиловались и запилили ант плагин к мавену, что вообщем хоть как то, но выручает.Отсюда кстати и поползли холивары.
Документация к мавену ужасна. Только гугл, только stack-overflow.
Кодировка исходников и версия джавы под которую они написаны прописывается неявным образом:

    <properties>
        <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
        <jdk>1.6</jdk>
    </properties>

    <build>
        <plugins>
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-resources-plugin</artifactId>
                <configuration>
                    <encoding>${project.build.sourceEncoding}</encoding>
               </configuration>
            </plugin>

            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-compiler-plugin</artifactId>
                <configuration>
                    <source>${jdk}</source>
                    <target>${jdk}</target>
                    <compilerVersion>${jdk}</compilerVersion>
                </configuration>
            </plugin>
        </plugins>
    </build>

И даже тут есть проблема: нужно укзывать версию стандартных плагинов. Какую ёё прописывать непонятно.

Упаси бог написать вам свой java agent — они не поддерживаются на уровне конфигурации мавена. И даже плагина ещё нет.
В итоге для прогона юнит тестов библиотеки javaagent приходится изголятся таким образом:

            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-surefire-plugin</artifactId>
                <configuration>
                    <forkMode>pertest</forkMode>
                    <argLine>-javaagent:${project.build.directory}${file.separator}${project.build.finalName}.${project.packaging}</argLine>
                    <workingDirectory>${project.build.directory}</workingDirectory>
                </configuration>
            </plugin>

И при первом прогоне оно не работает, посокольку джарника ещё нет, а мы уже к нему обращаемся.
Но как ни странно стадия тестов от этого не валится и он таки билдитcя. Мрак.

И так же тут всплывает ещё одна проблема: в пропертях мавена нет пути к сбилдженому артефакту.
Приходится самому её имитировать:
${project.build.directory}${file.separator}${project.build.finalName}.${project.packaging}

Кстати сами проперти в отдельный файл никак не вынесеш, как это сделано в анте.

settings.xml явно не самая удобная вещь. И непонятно почему репозитории не перенесены туда.

Не до конца понятный build lifecycle:

  • clean и site запускается только вручную, по сути это самостоятельные таргеты а пункты лайфцайкла.
  • install это совсем не то что что и install в make.
  • deploy тоже у всех ассоциируется немного с другим процессом.

С версииированием артифактов всё тоже не всегда хорошо. Дописывать alpha beta к релиз пакетам геморно (через плагин). А ведь это вполне стандартная система версиирования.

Вообщем недостатков много, и всё равно в основе мавена лежит очень правильная идея: описывать проект, а не процесс его создания. Это очень правильная философия.

UPD
Интересная статья Maven is broken by design