Maven tips. Опции для многомодульных проектов

Тем из нас кто в качестве билд тулзы использует maven посвящается.
Ежедневно нам приходится десятки раз пересобирать проект. Это занимает от нескольких секунд до минут рабочего времени, которые можно было бы провести более полезно нежели тупо наблюдая за выполнением процедуры билда. В данной заметке рассмотрим пару уловок, позволяющих оптимизировать время на сборку проекта.

1. rf опция.

Большинство больших проектов разбиваются на несколько модулей, при этом запустив сборку родительского проекта запускается сборка всех дочерних. При падении сборки на одном из последних дочерних проектов, исправление ошибки и повторный перезапуск сборки приведёт к сборке всех всех модулей. Специально для таких случаев придумана опция resume(mvn -rf [родительский проект]), которая запустит билд с последнего поломанного проекта, не пересобирая уже собранные.

2. pl опция.

Ещё одна опция упрощающая жизнь, позволяет собирать только указанные проекты. В тех случаях когда нет необходимости собирать весь проект, а нужны только некоторые его модули можно воспользоваться опцией pl:

mvn -pl [модуль1],[модуль2] clean install

UPD.

Эмпирическим путём было установлено что опция pl является транзитивной. Тоесть если ваша структура проекта выглядит следующим образом:

корень

-модуль1

-модуль2

--сын_модуля2

-модуль3

--дочь_модуля3

И если вам необходимо сбилдить модуль1 и дочь_модуля3, то это возможно сделать с помощью следующей команды:

mvn -pl <модуль1>,<модуль3\дочь_модуля3> clean install

по мотивам 5 Maven Tips by Shekhar Gulati

Андрей Аксёнов. Прекращаем писать код.

Видео о BEST PRACTICES в программировании.

Apache Commons. Вывод всех "пропертей бина"

Работа программиста полна рутинных задач, которые делают её скучной и не интересной. Одной из таких задач есть переопределение стандартных методов: equals, hashCode, toString и др.
Не знаю как вы, но я метод toString в своих классах использую в основном для логгирования всей возможной информации об экземпляре класса. Так вот, в классах с большим числом пропертей (бинах) зачастую метод toString выглядит ужасно архаично. Кроме того при добавлении новых пропертей зачастую забывается добавить его вывод в toString, что добавляет проблем при будущих исследованиях ошибок. Рассмотрим на примере класса Student.

class Student {
String name;
Integer course;

public String toString() {
return "Имя: " + name + "Курс: " + course==null?"":course.toString();
}
}

Всё просто и примитивно, но не красиво, сложно и не сразу понято.
Специально для решения данных проблем в Apache Commons был создан класс ToStringBuilder, который самостоятельно соберёт строку или несколько строк из всех пропертей вашего класса. В результате использования данного класса наш пример примет следующий вид:

class Student {
String name;
Integer course;

public String toString() {
return ToStringBuilder.reflectionToString(this);
}
}

П.С.: По аналогии с ToStringBuilder в указанной библиотеке есть EqualsBuilder, HashCodeBuilder, CompareToBuilder которые также являются весьма полезными.

Мониторинг Java процессов

Линукс предоставляет замечательную утилиту ps, которая с опциями -ex позволяет получить полную информацию о запущеных java процессе, вместе с его Id(pid), и передаными параметрами. Но что же делать Windows пользователям? Диспечер задач довольно скуден и выбрать из списка в 5-6 java.exe интересующую просто не возможно.

Но выход есть. JDK предоставляет утилиту для мониторинга процессов под названием Java Virtual Machine Process Status (jps).

Использование:

cd %JAVA_HOME%\bin

и выполняем

>jps

для того что бы получить список запущеных Java процессов (JVM) и их ид.

>jps -v - кроме выше указаного выдаст нам детальную информацию о параметрах запуска.

Использование целочисленного типа данных для размещения логических переменных

Представим себе что у нас есть некоторый объект, который описывается рядом логических параметров (флагов). Например объект у нас будет "спорткомплекс" , а параметрами
1) наличие тренажёрного зала - да/нет
2) наличие басейна - да/нет
3) наличие фитнес центра - да/нет
4) наличие футзала - да/нет
5) наличие боксёрского ринга - да/нет
и т.д.
Задача довольно проста, найболее эффективным образом хранить эти все параметры.
Самым тривиальным является вариант создания 5 булевых членов нашего класса, каждый из которых будет отвечать за свой параметр. Кроме простоты реализации, в памяти эти параметры для каждого экземпляра класса будут занимать всего лишь по 5 бит (1 boolean = 1 bit). Но, что произойдёт если надо передавать такую информацию по сети, да ещё и в более менее осмысленном виде, например в хмл. Каждый из параметров обростёт дополнительными тегами, в результате чего его размер возрастёт в несколько раз. Более того, формирование такого хмл самого по себе потребует определённых ресурсов. Необходимо найти более оптимальный метод хранения этих флагов.
Для решение этой задачи можно воспользоваться типом данных int. Как известно, целочисленный тип данных в джаве состоит из 4 байт - 32 бит. Если представить int в двоичном формате, то это будет ряд из 32х нулей и единиц, а это значит что мы можем разместить в нём аж 32 логических переменных. Для оптимального сохранения boolean переменных в int переменной удобно воспользоваться операцией побитового сдвига.
Например, для размещения флагов из выше изложенного примера, мы воспользуемся первыми 6тью битами целого числа (1й бит будет рабочим, и флаг в нём храниться не будет).
Итак, для примера, что-бы сохранить первые два флага в общей int переменной можно воспользоватся следующим кодом:

// set flag 1
int flag1 = 1; // flag = 0 / 1
int flagPosition = 1;
i = i + (flag1<<flagPosition);
// set flag 2
int flag2 = 1; // flag = 0 / 1
flagPosition = 2;
i = i + (flag2<<flagPosition);
System.out.println(i);

В результате на экран выведется число 6. В двоичной системе 6 = 110, и если отбросить первый служебный 0, то видим что оба флага установлены в единицу. Данный пример можно преобразовать в унифицированную функцию, например следующего вида:
...
int flags = 0;

void setFlags(int flagValue, int flagPosition) {
flags = flags | (flagValue<<flagPosition);
}
...

Данная оптимизация не даст выиграша в памяти при хранения экземпляра класса, но даст возможность более эффективно (де)сериализировать, и пересылать набор флагов по сети.