среда, 7 декабря 2011 г.

Maven plugins which I use

В этом посте я расскажу о 10 плагинах Maven, которые я использую и которые могут оказаться вам полезными.

Чекеры

К этой группе относятся плагины-обёртки над различными утилитами для проверки кода:


Что о них можно сказать? Все они у меня запускаются при запуске mvn verify и останавливают сборку, если что-то нашли.

На настройку CheckStyle под себя пришлось потратить некоторое время — нашел правила в интернете, прогнал на своём коде и потом исправлял либо код, либо настройки чекера, либо добавлял исключения в специальный файл. Где-то пришлось ему уступить и чуть-чуть изменить свой стиль. Частично я даже узнал для себя немного нового из хороших практик (например, что в класс с утилитами, где все методы статические желательно добавлять приватный конструктор и объявлять класс как final).

Pmd плагин я пока запускаю только на рабочем проекте. Также плагин умеет запускать и cpd (Copy&Paste Detector). На своём проекте они не запускаются т.к. пока не удалось их подружить с Lombok-ом — PMD выдаёт ложные срабатывания, т.к. не видит геттеры и сеттеры.

Cobertura используется для измерения покрытия кода тестами. Из альтернатив пробовал Emma, но здесь мне графики больше понравились :) Из удобств, это возможность настроить барьер при котором сборка обрывается. Например, я настроил, чтобы для слоя с бизнес логикой code coverage всегда был не менее 100% Правда, во всём нужно знать меру: со мной было, когда не программы работали для человека, а я для них — как-то я отключал сборку проекта в CI, потому что надо было закоммитить код, который ещё не был покрыт тестами. Естественно всё зависит от вас, от того как вы будете использовать этот инструмент.

Утилиты

Есть парочка очень, на мой взгляд, полезных плагинов, которые можно вызвать из командной строки (ничего предварительно не настраивая в pom.xml), которые проинспектируют ваш проект и выдадут некую интересную информацию.

maven-dependency-plugin поможет вам разобраться в зависимостях проекта. Например, запустите mvn dependency:tree для того, чтобы увидеть все зависимости проекта в древовидном виде. Кроме непосредственных зависимостей, прописанных вами, вы увидите также и транзитивные. Плагин имеет ещё несколько опций, поэтому я рекомендую особенно любознательным пройти по ссылке выше и ознакомиться с остальными возможностями.

Один из самых любимых мной плагинов это versions-maven-plugin Он сверяется с репозиториями и подсказывает какие зависимости можно обновить до более новых версий. Попробуйте запустить versions:display-dependency-update и убедитесь сами! Аналогичная команда есть и для проверки версий плагинов: versions:display-plugin-updates

Небольшая ложка дёгтя в бочку мёда: не все апстримы придерживаются правил версионирования своих проектов и поэтому часто бывает, что Maven вам говорит, что у вас старая версия, а это не так (например, у меня такое с Spring Framework-ом и Hibernate-ом). Причем я сходу не нашел способа как добавить их в список исключений, чтобы они не маячили перед глазами каждый раз :( (Если вы знаете как, то поделитесь.)

Генераторы

Не так давно я для себя открыл maven-javadoc-plugin — теперь у меня есть свежая документация, которая легко генерируется из исходников командой mvn javadoc:javadoc Благодаря ему я стал больше внимания уделять вопросам документирования, чему очень рад, ведь теперь качество моего кода стало ещё лучше!

Плагин hibernate3-maven-plugin просто бесценен! Он позволяет генерировать всё из всего :) Я использую только генерацию схемы БД (DDL) на основании сущностей (т.е. Java классов). Безумно удобно! Например, когда я точно не уверен как работает та или иная JPA аннотация, я добавляю её, генерю схему и смотрю что получилось. (Буквально сегодня я так с @ManyToMany разобрался.) Также мне кажется удобным то, что можно на лету создавать схемы для различных БД — для интеграционных тестов я использую HSQL, в то время как для боевых целей у меня MySQL. Если мне придётся переезжать с MySQL на что угодно ещё, меня это абсолютно не пугает.

Остальные

Напоследок у меня остались:


maven-failsafe-plugin используется для интеграционных тестов. Он позволяет выполнить какое-либо действие до и после запуска тестов. И тут мы плавно переходим к Jetty плагину, который я запускаю до тестов и останавливаю после. (В итоге получается красивая картина: мы запускаем интеграционные тесты, стартуем легковесный сервлет контейнер, деплоим в него наше приложение, потом прогоняем тесты, например, на Selenium-е, а далее всё это корректно выключаем.)

Последним в списке значится maven-license-plugin, который позволяет следить за тем, чтобы во всех файлах были проставлены корректные хедеры с лицензией. Это актуально для open source проектов, на стадии их публикации, когда надо добавить во все файлы хедер с лицензией, а файлов очень много. Кроме того, он может проинспектировать уже существующий проект и указать где и что пропущено или оформлено не так как должно быть. Кому-то это покажется мелочью, но, как говорил Шерлок Холмс, «нет ничего важнее мелочей».

2 комментария:

  1. Хотел бы добавить кое что от себя про EclEmma и Cobertura. Первый - это плагин для эклипса, который позволят наглядно оценивать покрытие прямо в IDE с очень удобным интерфейсом и отчётами. Но он не лишён некоторых проблем с оценкой покрытия (на вскидку забыл детали - то ли он показывает лишнее покрытие, толи наоборот не учитывыает какие то вещи).
    Cobertura же в свою очередь является утилитой запускаемой из командной строки и может быть лишь интегрирована с системами сборки (не IDE) и разарботчику unit-тестов никак не помогает на этапе создания тестов.
    По поводу 100% покрытия тестов. Как показал мой опыт, реальное значение к которому надо стремиться - 90%. Есть куча вещей, под которые сложно написать тесты, например генерация разных редких exceptions. Часто у нас в коде есть блок try/catch потому что того требует вызов какого-либо метода, но реально такую ошибку в unit-тесте воссоздать нельзя.
    По поводу остановки сборки если покрытие менее 100%. Я думаю что это неразумно и в тоже время правильно. Всё зависит от системы контроля версий и способа работы с кодом. Грубо говоря, надо иметь под-стримы в которые вы можете коммитить любой код и стримы верхнего уровня, в которых должен лежать стабильный и протестированный код. Так вот для стримов верхнего уровня можно ставить жёсткие условия (вроде 90% покрытия тестами), а для нижних - такое условие можно вообще отключить. Таким образом одновременно наблюдаются production и development версии на предмет корректности и работоспособности.

    ОтветитьУдалить
  2. По поводу PMD: в IntelliJ IDEA есть куча разных встроенных помощников (утилит) которые анализируют каждую строчку твоего кода на предмет возможных багов и прочего. И можно видеть всё это прямо сразу - как в окне с ошибками компиляции.

    ОтветитьУдалить