← All posts tagged gradle

develar
Maven gradle love #1132294 еще не перешел на gradle. небольшая резкость моих постов вызвана желанием подстегнуть немного читателей к дискуссии. так же я идиот, то есть да, немного, если я правильно понял, "религиозен" — для меня инструмент не может быть проституткой — develar.livejournal.com Тот факт, что тул почти полностью устраивает за исключением пары "мелочей", не может быть оправданием забить на изучение иного тула, который потенциально лучше и удобнее.

Да, "А Gradle какая то хрень между maven и ant.", именно, "хрень", и именно она лучше подходит для моего проекта. И не только с точки зрения удобства написания собственно build-скрипта, но и описанных нюансов с отдельной сборкой (вне dep management) java-части проекта и плагинов.

Если тебя как консультанта волнует момент как это отображается на рабочем графике — то да, мечта останется мечтой — мне в свободное время будет интереснее пилить свой основной проект, а не заниматься этой ерундой под капотом. Но это никак не отменяет того факта, что мавен сосет. И ранее написанные посты, как мавен бибикает были посвящены не собственно продукту как таковому, и концепции — а в gradle они сохранены + ряд других плюшек (которые так нужны мне на текущем проекте).
develar
gradle IDEA Flex OMG. Оказывается, built-in compiler shell в IntelliJ IDEA неинкрементальный. У меня проект маленький, я особо и не заметил. Заметил только, что компиляция стала незаметной и типа быстрее. Но ведь никто и тут в жуйке не жаловался на ухудшение скорости компиляции на больших проектах.

Отсюда два возможных вывода:
1) компилятор настолько убог, что есть или нет инкрементальность толку мало, достаточно того, что программисты в Jetbrains думают головой и для обхода убогого компилятора не дергают его, а сами следят за фактом необходимости компиляции модуля (то есть убожество компилятора таково, что если поменялся хоть один файл, то оно в любом случае перекомпилирует все).
2) никто им не пользуются.

Очевидно, что в плагине flex gradle инкрементальности не будет.
develar
Maven gradle maven сосет. gradle позволяет подключить в качестве dep resolve что угодно — хоть local dir. Решено — искоренить мавен и написать плагин для сборки флекса к gradle.
develar
Maven 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, работал над основным проектом по работе.
develar
Maven 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 — и то, после этого я должен после сборки совершать ряд шаманских действий (потому что писать полноценный плагин в мавене для решения такой проблемы — проще застрелиться). И на предыдущем проекте у меня была такая же песня.