Author Archives: elwood
Почему-то всегда считал, что если делать трассировку в отладчике (Step In, Step Over), то все остальные потоки в это время приостановлены, поскольку все потоки приостанавливаются при остановке на брейкпоинте. А оказалось, что это не так, и хотя IDEA действительно останавливает все потоки при попадании на точку останова, при дальнейшей трассировке между каждым следующим шагом вся JVM полностью возобновляется. Здесь чел тоже плачется и хочет режим, в котором бы трассировка не возобновляла остальные потоки. На что ребята из JetBrains пока что отвечают, что всё работает, как и должно, by design, и что это и есть правильный подход, т.к. в противном случае могут возникать дедлоки.
Мне кажется, что всё же опция отладки в таком режиме необходима, потому что иначе трассировать многопоточное приложение просто не имеет смысла. Буду надеяться, что фичу одобрят и добавят в будущем. А пока этого не случилось, приглашаю проголосовать за неё в трекере:
Научился сегодня по-простому делать профили а-ля мавно. Рецепт таков:
1) Создаём файл defaults.gradle. В нём будут лежать значения свойств по умолчанию, например:
allprojects { ext { // Solr connection host = 'localhost' port = '8983' username = '' password = '' } } project(':crawler') { // SQL Server connection project.ext["jdbc.url"]='jdbc:jtds:sqlserver://...' project.ext["jdbc.username"] = 'user' project.ext["jdbc.password"] = 'passasdf' project.ext["jdbc.driverClassName"]='net.sourceforge.jtds.jdbcx.JtdsDataSource' } |
2) Для каждого профиля создаём файл с именем profile-${profile}.gradle, например, файл profile-stage.gradle:
allprojects { ext { host = '234.23.42.3' port = '6001' username = '' password = '' } } |
3) В основной скрипт сборки build.gradle в начало добавляем следующий код:
apply from: "defaults.gradle" if (hasProperty('profile')) { apply from: "profile-${profile}.gradle" } |
Таким образом, defaults.gradle будет применяться всегда, а скрипт, специфичный для конкретного профиля – только если указывается свойство profile.
4) Запустить сборку с указанием профиля:
gradlew -Pprofile=stage :crawler:build
Если вы только что собрали что-то с одним профилем, а потом решили пересобрать для другого, убедитесь, что gradle прознал о том, что что-то надо пересобрать. Например, если вы используете Ant Filtering, то градло не поймёт, что ресурсы надо пересобрать – нужно явно выполнить clean.
Сегодня Тимур мне рассказал, что для градла есть удобнейшая штука – враппер. Например, вы используете gradle с версией X (икс). И ваш скрипт сборки точно будет работать на этой версии. Будет ли он работать на других версиях – вопрос. Программист, скачавший ваш репозиторий с кодом и скриптами сборки, вынужден будет установить у себя такую же версию градла. Неудобно. Но градло спешит на помощь ! Можно добавить в build.gradle следующее:
task wrapper(type: Wrapper) { gradleVersion = '2.0' // Желаемая версия } |
и после этого выполнить команду gradle wrapper, которая сгенерирует следующие файлы:
gradlew gradlew.bat gradle/wrapper/ gradle-wrapper.jar gradle-wrapper.properties |
Эти файлы нужно закоммитить (да-да, джарник тоже, но он крошечный). И теперь чтобы собрать проект, достаточно вместо gradle использовать gradlew:
gradlew build |
Враппер сам скачает нужную версию градла, поместит её в .gradle-кеш и использует её для сборки. Таким образом, пользователю, скачавшему ваш репозиторий, вообще ничего не нужно делать, кроме запуска bat-файла (или shell-скрипта в не-Windows системах) ! Вот такой вот best practice. Разве не блистательно ?
0