Category Archives: Tools
Те, кто плотно пользуются мавном, наверняка знают и активно используют плагин maven enforcer. Если включить проверку DependencyConvergence, то плагин будет проверять проект на отсутствие конфликтов между версиями используемых артефактов:
<plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-enforcer-plugin</artifactId> <version>1.0.1</version> <executions> <execution> <id>enforce</id> <configuration> <rules> <DependencyConvergence /> </rules> </configuration> <goals> <goal>enforce</goal> </goals> </execution> </executions> </plugin> |
У него есть ещё проверки, но самая важная именно эта. Например, в проекте используется log4j версии 1.2, а какая-то библиотека в одной из транзитивных зависимостей ссылается на log4j 1.1, то enforcer ругнётся во время сборки. После этого программист увидит проблему и пойдёт чинить. Как правило, для решения траблы достаточно замаскировать часть транзитивных зависимостей с помощью exclude. Если же этого не сделать, а отключить enforcer, то в билд попадут обе зависимости: и log4j:1.2, и log4j:1.1, что не очень хорошо, так как то, какая версия будет реально использована, зависит лишь от порядка его нахождения в classpath.
В gradle же по умолчанию работает следующая схема. Если есть конфликт, то будет использована крайняя версия артефакта, и дублей в результирующем билде не будет. И — черт возьми — в 99% случаев это именно то, что надо ! Но душа взывает к возможности полного контроля за ситуацией. Хочется, чтобы при появлении конфликтующей зависимости программист сразу об этом узнал и на всякий случай проверил ещё раз руками. Если у вас такая же параноя — вы можете установить другой режим разрешения конфликтов (благо грейдл это позволяет):
configurations.all { resolutionStrategy { // Fail eagerly on version conflict (includes transitive dependencies) // e.g. multiple different versions of the same dependency (group and name are equal) failOnVersionConflict() } } |
Всё, теперь сборка будет фейлиться при появлении конфликтов. Разрешать эти конфликты вам придётся самостоятельно, опять же с помощью exclude’ов, либо пользуясь force-установкой версий артефактов (см. документацию).
Единственный минус этой схемы по сравнению с maven enforcer в том, что enforcer вываливает все конфликты сразу, а gradle будет фейлиться на каждом конфликте по одному 🙂 В общем, занятие чистить руками конфликты это минимум на полчаса ковыряний с gradle :dependencies.
А вообще, режим градла по умолчанию очень разумный, в принципе, можно ничего и не трогать, всё будет работать (почти всегда).
Дали мне ссылку на один сайт. Ссылка была обычная http. Захожу – и броузер упорно редиректит на https версию сайта, на которой сайт недоступен. В консоли броузера при этом написано что-то необычное:
При этом curl запрос на этот же сайт по http ничего странного не выдаёт – обычная HTML страница.
Так я открыл для себя Http Strict Transport Security.
Как выяснилось, эта штука работает так: если я как-то раз зашёл на https версию этого сайта и получил при этом заголовок Strict-Transport-Security, то броузер запоминает этот домен, и начинает редиректить на него все обращения по http автоматически. Что у меня и происходило.
Для Яндекс.Броузера мне подсказали унутреннюю страничку, доступную по адресу http://about:net-internals#hsts. В ней можно удалить правило для домена.
В рамках продолжения работ по плагину FreeMarker для MyBatis нужно было сделать сайт проекта, по аналогии с тем, как это сделано у mybatis-velocity. С сайтами такого рода я сталкивался неоднократно, но до этого не задумывался о том, как такие сайты делаются. Поэтому пришлось «реверсить» метод создания сайта. Посмотрев на верстку и погуглив, я обнаружил, что это – результат выполнения команды mvn site. Однако на исходниках mybatis-velocity эта команда почему-то выдавала другой результат: сайт был похож, но стили были старые, отсутствовал логотип, и не было целой группы разделов «Project Reports». Допустив, что часть конфигурации находится в родительском pom.xml и берётся откуда-то из другого места, я стал шаманить с конфигами, пытаясь добиться, чтобы mvn site выдавал точно такой сайт, который был выложен на github-pages. Через некоторое время мне это удалось, и я сделал всё по аналогии для своего проекта. И заодно решил написать гайд по тому, как это сделать.
Итак, в мавне есть встроенный механизм для генерации шаблонных сайтов проектов. В сгенерированном сайте автоматом будет инфа о полученном артефакте, о том, какие зависимости у него есть, как прописать артефакт к себе в pom.xml, список участников проекта, и ещё много разных отчётов. По умолчанию список генерируемых отчётов весьма велик, его можно уменьшить, а можно добавить ещё 🙂 Для того, чтобы вся балалайка завертелась, нужно запилить site.xml. В нём прописываются настройки меню, внешнего вида сайта. Можно выбрать плагин для стилей – по умолчанию будет старенький стиль, fluido на бутстрапе выглядит поприкольнее. В папке xdocs уже пишется сам контент. Формат простой и интуитивно понятный – я за полчаса по аналогии забацал свою страничку «Getting started». Одно тонкое место – чтобы избежать лишних пробелов до и после кодовой разметки, нужно чтобы не было пробелов между тегами <source/> и собственно исходным кодом. Ну и очень желательно уметь использовать <![CDATA[]]>.
Далее, дополнительные плагины. Очень рекомендую встроить javadocs. Это, думаю, самое полезное. Для того, чтобы отчёт сгенерился вместе с остальными, достаточно добавить его в <repoting/>. У меня был какой-то баг при генерации джавадоков, почему-то не компилировались классы из test. Пришлось заигнорить goal javadoc-test.
После того, как мавно сделает вам сайт, вы можете его просто залить на GitHub Pages – либо в отдельный репозиторий, либо в этот же проект веткой gh-pages.
В остальном проще не расписывать подробно, что к чему, а просто дать ссылку на пример того, как это настроено в моём случае: https://github.com/elw00d/mybatis-freemarker. Можно просто копировать конфиги и изменять по своему усмотрению.
0