Ещё про Gradle. В одном проекте, который начинался ещё до прихода Gradle в Android, я реализовал похожую систему для кастомизации с сборки нескольких apk поверх обычного ant на баше. И это всё уже два года не ломается, работает быстрее и не портит мои нервы.
Я периодически думаю выпилить это всё и внедрить Gradle, но каждый раз убеждаюсь насколько это плохая идея.
Оказывается, manifestPlaceholders работает только в определённых местах манифеста и можно использовать только одно (!) значение.
Что такое gradlew и зачем он нужен?
Почему андроид студия при импорте проекта спрашивает у меня Gradle home? Зачем это вообще?
Gradle не умеет игнорировать дублирующиеся файловые зависимости
Видеосравнение (~50мин) инструментов сборки #gradle и #maven.
java-tv.com
А меж тем негры нашлись — github.com
Эй, джавалюбы, кто работал с Gradle? Как там плагины подключать?
#1132294 еще не перешел на gradle. небольшая резкость моих постов вызвана желанием подстегнуть немного читателей к дискуссии. так же я идиот, то есть да, немного, если я правильно понял, "религиозен" — для меня инструмент не может быть проституткой — develar.livejournal.com Тот факт, что тул почти полностью устраивает за исключением пары "мелочей", не может быть оправданием забить на изучение иного тула, который потенциально лучше и удобнее.
Да, "А Gradle какая то хрень между maven и ant.", именно, "хрень", и именно она лучше подходит для моего проекта. И не только с точки зрения удобства написания собственно build-скрипта, но и описанных нюансов с отдельной сборкой (вне dep management) java-части проекта и плагинов.
Если тебя как консультанта волнует момент как это отображается на рабочем графике — то да, мечта останется мечтой — мне в свободное время будет интереснее пилить свой основной проект, а не заниматься этой ерундой под капотом. Но это никак не отменяет того факта, что мавен сосет. И ранее написанные посты, как мавен бибикает были посвящены не собственно продукту как таковому, и концепции — а в gradle они сохранены + ряд других плюшек (которые так нужны мне на текущем проекте).
@develar все таки религиозен. Разочаровавшись слегка в одной религии, решил напасть на другую, как разочаровавшиеся христиане убегают в ислам или саентологию. А Gradle какая то хрень между maven и ant. Единственная причина почему можно терпеть maven — он стандартизирован, В отличии от Ant, который каждый пишет в зависимости от настроения и вдохновения. Не буду никому его рекомендовать =)
OMG. Оказывается, built-in compiler shell в IntelliJ IDEA неинкрементальный. У меня проект маленький, я особо и не заметил. Заметил только, что компиляция стала незаметной и типа быстрее. Но ведь никто и тут в жуйке не жаловался на ухудшение скорости компиляции на больших проектах.
Отсюда два возможных вывода:
1) компилятор настолько убог, что есть или нет инкрементальность толку мало, достаточно того, что программисты в Jetbrains думают головой и для обхода убогого компилятора не дергают его, а сами следят за фактом необходимости компиляции модуля (то есть убожество компилятора таково, что если поменялся хоть один файл, то оно в любом случае перекомпилирует все).
2) никто им не пользуются.
Очевидно, что в плагине flex gradle инкрементальности не будет.
Градл предоставляет слишком большую гибкость. И не ясно, как эта гибкость будет интегрироваться с workflow в IDE. Меня мавен подкупил именно интеграцией со средсвом разработки. Систему для сборки и деплоя можно и на баше написать — гибко, что пиздец. В свое время мы на переход с баша на ант въебали столько времени, что лучше было бы оставить все на баше. Представляю, сколько бы мы въебали времени на мавен. Архитектура новых проектов отталкивается от возможностей мавена, по этому все работает относительно хорошо.
Таак. Значит @prime знает что-то о gradle и на ITForest 2010 молчал об этом как партизан. Вы собираете сейчас через ант-таски, верно?
maven сосет. gradle позволяет подключить в качестве dep resolve что угодно — хоть local dir. Решено — искоренить мавен и написать плагин для сборки флекса к gradle.
"С gradle не чувствуешь себя с завязанными руками как в ant или с руками застёгнутыми наручниками между ног как в maven." (© m-a-m-o-n.livejournal.com )
Как дурак сейчас каждый раз после мавен-импорта проекта ручками ставлю модульную зависимость в IDEA — потому что оно через Embed включается в другое приложение, а через мавен такую зависимость никак не укажешь. А в Gradle все просто gradle.org
ideaProject {
withXml { provider ->
provider.node.component.find { it.@name == 'VcsDirectoryMappings' }.mapping.@vcs = 'Git'
}
}
Но я тряпка – вместо того, чтобы в выходные написать плагин для мате или gradle, работал над основным проектом по работе.
"You can choose what is right for your domain and find the right balance between unnecessary indirections, and avoiding redundancy and a hard to maintain code base. It is our experience that even very complex custom build logic is rarely shared between different builds. Other build tools enforce a separation of this build logic into a separate project. Gradle spares you this unnecessary overhead and indirection." Да, иногда есть такие штуки — на текущем проекте я оперирую байт-кодом — и логика эта реализована в классе, который никак не связан с мавеном (и собирается вообще отдельно и ни за какие идеалы невозможно это изменить) и работает только в runtime — но для тестов и при работе в отладочном режиме нужно чтобы на момент build complete соответствующие артефакты были обработаны. В мавене это решается жуткой порнографией с созданием отдельного плагина + system dep с systemPath к кастомному jar — и то, после этого я должен после сборки совершать ряд шаманских действий (потому что писать полноценный плагин в мавене для решения такой проблемы — проще застрелиться). И на предыдущем проекте у меня была такая же песня.
Агитка для неверующих — prezi.com
Кто пишет плагин к Gradle для флеша? Почему все молчат?
Maven — неудачник habrahabr.ru