Будувати Java програму без Maven чи Gradle? - javascript.org.ua

Так, це можливо за допомогою деякого сценарію, давайте розглянемо рішення, орієнтоване на bash!

Коли ми будуємо проєкт, будь-який Java проєкт, і вам потрібно обмежене число ресурсів, і ви не хочете додавати складність за допомогою інструментів для побудови (Maven, Gradle, Ant), саме в цей момент я використовую можливості BASH 🙂

Що таке побудова (build)?

Побудова складається з різноманітного компілювання вихідного коду в бінарні артефакти, які використовуються/виконуються.

Але це також гарний момент, щоб

виконати автоматизовані юніт-тести,
згенерувати документацію проєкту (JavaDoc або для іншого),
підготувати артефакти для доставки, такі як zip-архіви або виконувані файли.

Усі ці кроки повинні бути враховані в нашому власноруч розробленому рішенні, але з обмеженим набором доступних інструментів у стандартному Linux терміналі або в Microsoft Windows терміналі з допомогою git-bash.

Спочатку компілюємо Java вихідні файли

Ми будемо використовувати незамінний JDK для компіляції нашого Java коду:

javac MyClass.java

Це створить файл MyClass.class, що є результатом процесу компіляції.

Але для того, щоб отримати корисний артефакт, нам потрібен хоча б JAR. Ось тут ми потребуємо більш складного механізму.

Складність javac, яку потрібно приборкати

Якщо подивитись на стандартну команду:

ми можемо використовувати всі ці можливості для побудови нашого програмного забезпечення:

javac $COMPILATION_OPTS \  
 -d $CLASSES \  
 -g:source,lines,vars \  
 -source $SOURCE_VERSION \  
 -target $SOURCE_VERSION \  
 -cp ".${FS}${EXTERNAL_JARS}${FS}${CLASSES}" @$TARGET/sources.lst

Ми можемо налаштувати:

деякі COMPILATION_OPT[ion]S,
встановити місце для збереження зкомпільованих артефактів у шлях CLASSES,
вказати сумісність з конкретною версією SOURCE_VERSION,
визначити цільову версію за допомогою того ж параметра,
сформувати classpath (cp) з зкомпільованих класів та підключити деякі EXTERNAL_JARS бібліотеки.
І, нарешті, надати список джерел класів для компіляції з TARGET.

І завдяки bash-командам, ми будуємо цей sources.lst за допомогою команди find:

find $SRC/main -name '*.java' >$TARGET/sources.lst

Тепер ми маємо всі скомпільовані класи у цілі, з посиланнями на зовнішні бібліотеки.

Перевірка якості коду

Тепер, це гарна практика компіляції з перевіркою якості коду. Для цього ми будемо використовувати інструмент CheckStyles для проведення статичного аналізу зкомпільованого коду:

java $JAR_OPTS -cp "$LIB_CHECKSTYLES${FS}$EXTERNAL_JARS${FS}$CLASSES:." \  
 -jar $LIB_CHECKSTYLES \  
 -c $CHECK_RULES_FILE \  
 -f xml \  
 -o $TARGET/checkstyle_errors.xml \  
 @$TARGET/sources.lst  
 xsltproc -o $TARGET/checkstyle_report.html $LIBS/tools/rules/$CHECKSTYLE_REPORT_XSL $TARGET/checkstyle_errors.xml

Таким чином, інтегруючи всі залежності та наші зкомпільовані класи в classpath, ми можемо виконати інструмент перевірки стилю з певним набором правил перевірки.

Ми будемо використовувати 2 варіанти:

правила перевірки стилю Sun,
правила перевірки стилю Google.

Обидва варіанти надаються через XML конфігураційний файл.

Для найбільш зацікавлених осіб, ви можете перевірити, змінити та редагувати цей файл, щоб активувати/деактивувати необхідні правила перевірки, але оскільки ці два варіанти є стандартними, ви можете вибрати один з них.

Створення JavaDoc?

Тепер, коли ми створили звіт про перевірку якості коду, настав час звернутися до документації.

Оскільки ми витратили години на поліпшення наших inline JavaDoc, саме час витягти його у стандартний JavaDoc JAR файл нашого проєкту:

javadoc -source $SOURCE_VERSION \  
 -author -use -version \  
 -doctitle \"$PROGRAM_NAME\" \  
 -d $TARGET/javadoc \  
 -overview $SRC/main/javadoc/overview.html \  
 $JAVADOC_GROUPS \  
 -sourcepath "${SRC}/main/java${FS}${SRC}/main/javadoc" \  
 -subpackages "${JAVADOC_CLASSPATH}" \  
 -cp ".;$EXTERNAL_JARS"

Створення JAR з вихідним кодом

Немає гарної компіляції без публікації вашого відповідного версіонованого вихідного коду.
Ось тут і стає обов'язковим JAR з вихідними файлами.

jar cvf ${TARGET}/${PROGRAM_NAME}-${PROGRAM_VERSION}-sources.jar -C src .

Отже, ми архівуємо всі вихідні файли в один java-архів, названий за іменем програми та номером версії, щоб створити відповідний “*-sources.jar” файл.

Юніт-тести назавжди!

Після того, як весь код скомпільовано, задокументовано та архівовано, ми можемо приступити до виконання юніт-тестів.

Давайте перераховуємо класи та тести, які потрібно виконати, і виконуємо бібліотеку JUnit в автономному режимі:

find $SRC/main -name '*.java' >$TARGET/sources.lst  
find $SRC/test -name '*.java' >$TARGET/test-sources.lst  
javac -source $SOURCE_VERSION -encoding $SOURCE_ENCODING \  
 $COMPILATION_OPTS -cp ".${FS}$LIB_TEST${FS}${EXTERNAL_JARS}" \  
 -d $TEST_CLASSES @$TARGET/sources.lst @$TARGET/test-sources.lst  
java $JAR_OPTS -jar $LIB_TEST \  
 --cp "${EXTERNAL_JARS}${FS}${CLASSES}${FS}${TEST_CLASSES}${FS}." \  
 --scan-class-path

Опції

Ви також можете використати цей сценарій для створення документації з markdown файлів за допомогою утиліт pandoc.

очистити цільову директорію для генерації книги,
створити її, якщо вона не існує (?),
об'єднати всі markdown файли з шляху _src/docs_ в директорію призначення _book/_,
та виконати утиліту pandoc для перетворення markdown файлів у PDF.

rm -Rf $TARGET/book/  
mkdir $TARGET/book  
cat docs/*.yml >$TARGET/book/book.mdo  
cat docs/chapter-*.md >>$TARGET/book/book.mdo  
mv $TARGET/book/book.mdo $TARGET/book/book.md  
pandoc $TARGET/book/book.md \  
 --resource-path=./docs \  
 --pdf-engine=xelatex \  
 -o $TARGET/book/book-$PROGRAM_NAME-$PROGRAM_VERSION.pdf

Перегляньте офіційні сторінки pandoc для додаткової інформації: https://stackoverflow.com/questions/29240290/pandoc-for-windows-pdflatex-not-found

ПРИМІТКА
Щоб налаштувати книгу, ви можете використовувати файли *.yml з папки _src/docs.

Висновок

Це лише деякі з хороших bash-рецептів, які я використав у цій статті, щоб показати всю роботу, яку я виконав з моїм скриптом build.sh. Ви можете подивитися його та використати з цього gist файлу : https://gist.github.com/mcgivrer/3fe8a25a2815bca3a1a7f333f6944665.

Ви знайдете більше інформації в наданому README файлі з усіма деталями використання.

Насолоджуйтеся процесом побудови вашого Java коду, звільняючись від Maven, Gradle та інших великих інструментів. І пам'ятайте, що цей скрипт для побудови призначений для маленького Java проєкту.

Перекладено з: Build Java program without Maven or Gradle?