"Вспомогательная" цель в maven
От: Artem Korneev США https://www.linkedin.com/in/artemkorneev/
Дата: 05.11.18 22:42
Оценка:
Ковыряю тут на досуге вопросы защиты от NullPointerException в Java.

Пока выбрал такую связку:

— в коде — NotNull/Nullable аннотации от JetBrains
— чтоб не расставлять NotNull на каждой строчке, взять Null4J — оно дает аннотацию NotNullByDefault, которую можно влепить на весь класс и получить не-null по умолчанию. Оно там немного не в том виде, в каком мне надо, но для начала сойдет
— С IDE понятно — IDEA умеет отслеживать аннотации и подсвечивать возможные нарушения
— Чтоб контролировать следование этим аннотациям на уровне билда, берем связку из статического анализатора error-prone от Google + плагин NullAway от Uber к нему. Все плагины кроме контроля Null-аннотаций пока отключаем, для скорости.

Так вот.. этот самый error-prone работает как надстройка над компилятором и фактически в билде вызывается этот самый error-prone вместо javac. Оно как бы работает, но теперь некошерно, что продакшн-билд собирается этим анализатором, а не ванильной JDK. В нашем энтерпрайзе такой билд не примут, у меня несколько месяцев ушло на то чтоб аннотации от JetBrains одобрили. А билд, с использованием сторонней надстройки, скорее всего, тут же развернут.

По этим причинам, да и просто для собственного спокойствия, хочется чтоб error-prone вызывался не для основного билда, а как вспомогательная задача. Чтоб добавить в Maven какую-нибудь дополнительную цель, которая будет вызываться только для генерации отчета, но не для получения продакшен-бинарников.

Подскажите, как в Maven добавить такую цель? С Maven'ом я пока знаком несколько поверхностно. Посмотрел кое-какие руководства и курсы, но они все концентрируются на базовом функционале, не давая особых примеров и пояснений по дополнительным настройкам и расширению билдов.

Про другие анализаторы вроде FindBug/Spotbug знаю, игрался с ними. До error-prone они не дотягивают, ну или я не умею их готовить. Простейшие случаи вроде этого они ловят:

  @NotNull Object foo() {
    return null;
  }


А если логика чуть посложнее, то уже не ловят:

  @NotNull Object foo(int i) {
    return someMap.get(i); // <- тут возвращается null, если элемент не найден
  }


Error-prone + NullAway пока единственная комбинация, которая поймала нарушение аннотации на этом примере и некоторых других не-тривиальных случаях, которые я попробовал.
С уважением, Artem Korneev.
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.