Comments 60
Кстати о зависимостях. Кто-нибудь пробовал уже пользоваться JitPack? Если вкратце — сервис позволяет работать с Git-репозиториями, хостящимися на GitHub, как с Maven-зависимостями.
Есть ли вообще смысл работать с этим сервисом в ситуации, когда, например, в проекте используются чужие библиотеки с парой-тройкой фиксов/дополнений, нужных только вам (то есть pull-request авторам отправлять бессмысленно, вливать они его всё равно не станут)? Или же более безопасным/удобным/идеологически правильным способом будет поднять свой Maven-репозиторий и работать уже с ним?
Коммитить jar/aar в Git/Mercurial репозиторий кажется не самым удачным способом решения проблемы.
Есть ли вообще смысл работать с этим сервисом в ситуации, когда, например, в проекте используются чужие библиотеки с парой-тройкой фиксов/дополнений, нужных только вам (то есть pull-request авторам отправлять бессмысленно, вливать они его всё равно не станут)? Или же более безопасным/удобным/идеологически правильным способом будет поднять свой Maven-репозиторий и работать уже с ним?
Коммитить jar/aar в Git/Mercurial репозиторий кажется не самым удачным способом решения проблемы.
«более безопасным/удобным/идеологически правильным способом будет» использовать jcenter, деплой в который не требует недельных танцев с бубном, в отличие от maven central.
А можно я вас ещё немного поспрашиваю? Я просто ни разу ничего на jcenter не заливал, поэтому заинтересовался.
Как jcenter разруливает ситуации с кучей версий одной и той же библиотеки?
Есть, скажем, «com.example.library:foo:1.2.3». Я добавил в ней сбоку небольшой функционал, и теперь наверняка ведь не смогу залить её как «com.example.library:foo:1.2.4» (там наверняка же какие-то ключи используются, для подписи артефактов, чтобы удостовериться, что «com.example.library:foo» заливает один и тот же автор). Значит, придётся заливать её как «com.example.artemlibrary:foo:1.2.3».
А потом приходите вы, фиксите какой-то баг, добавляете функционал — и появляется «com.example.troylibrary:foo:1.2.3».
Ещё несколько итераций с разными разработчиками и появился зоопарк разных версий.
Оно так и работает, да? jcenter к подобным ситуациям нормально относится?
Как jcenter разруливает ситуации с кучей версий одной и той же библиотеки?
Есть, скажем, «com.example.library:foo:1.2.3». Я добавил в ней сбоку небольшой функционал, и теперь наверняка ведь не смогу залить её как «com.example.library:foo:1.2.4» (там наверняка же какие-то ключи используются, для подписи артефактов, чтобы удостовериться, что «com.example.library:foo» заливает один и тот же автор). Значит, придётся заливать её как «com.example.artemlibrary:foo:1.2.3».
А потом приходите вы, фиксите какой-то баг, добавляете функционал — и появляется «com.example.troylibrary:foo:1.2.3».
Ещё несколько итераций с разными разработчиками и появился зоопарк разных версий.
Оно так и работает, да? jcenter к подобным ситуациям нормально относится?
Да, вам будет необходимо использовать другой packageName, кроме уникальности packageName может быть уникальность packageGroup. Т.е. возможна ситуация когда вам понадобится публиковать «com.artemexample.library:foo:1.2.3».
По теме публикации библиотек в jCenter недавно на habrahabr была хорошая статья, советую почитать при необходимости.
По теме публикации библиотек в jCenter недавно на habrahabr была хорошая статья, советую почитать при необходимости.
UFO just landed and posted this here
Я постоянно пользую и всем навязываю: для форка отличное решение.
Я пробовал использовать, при отсутствии релиза в Maven/Ivy репозиториях и желанию попробовать содержимое Git репозитория JitPack удобен. Если автор не принимает pull-request, то ничего не мешает вам сделать полноценные форк и публиковать самостоятельно что считаю более хорошим вариантом.
Мы на работе держим свой репозиторий (Nexus) и туда деплоим такие штуки. Причём через мавен — выкачиваем опубликованный source artifact, добавляем свои изменения, с ними перекомпилируем и деплоим.
не хватает варианта: «никакую, ибо overhead». очень, очень высокий порог вхождения. не нужен такой для build системы. потому и не станет она широко распространена. и даже механизм dependency resolution её не спасет.
жаль, что её не пытаются привести в порядок. нужно всего-то привести в порядок документацию, и разработать жесткие conventions, раз уж выбрали такой неудачный язык.
жаль, что её не пытаются привести в порядок. нужно всего-то привести в порядок документацию, и разработать жесткие conventions, раз уж выбрали такой неудачный язык.
Здравствуйте,
интересная мысль – было бы интересно услышать её более развёрнуто.
интересная мысль – было бы интересно услышать её более развёрнуто.
на мой взгляд главная проблема — гибкость. из-за этого порог вхождения высок — новичок не может взглянуть на *.gradle и понять что он делает и в каком месте. а главное — куда ему вставить то, что он хочет сделать.
в мавене используется xml — из-за этого есть жесткая схема действия, выпрыгнуть из неё тяжело, проще сделать по конвенции.
там же в плагинах используются mojo — из-за аннотаций можно взглянув на плагин построить схему конфигурации, её тэги и возможные значения.
я не спорю — всему можно научится. но я умею пользоваться мавеном, его возможностей мне хватает.
авторы гредла, насколько я понимаю, увидели в мавене фатальный недостаток. и запилили свой dsl. это конечно, шутка.
реальная цель было объединить все возможные источники артефактов и билд-систем: maven, ivy, gant.
Но реализация подкачала, на мой взгляд. И не сможет объединить это все, а просто встанет рядом. (тут надо бы картинку про 15 стандартов вставить)
вот чего я не понимаю в грэдл («не понимаю» — в смысле не понимаю зачем авторы взяли такой подход):
— это groovy cо своим dsl. Почему groovy? Ладно, бог с ним, просто у автором в тот момент это было модным. В итоге статической проверки скрипта у нас нет. с синтаксисом тоже трудности. Вот есть блок (фигурные скобки). Это может быть просто блок. А может быть функция-параметр к предыдущей функции.
— gradle wrapper. мне тут трудно комментировать. я бы сделал один корневой тул, устанавливал бы его в систему и расширял плагинами. как в принципе и работает мавен. и даже ант себя с собой не таскает. Тут проблема именно в том, что gradle — это язык, и чтоб не пострадала обратная зависимость — «все свое ношу в собой».
— некоторые термины. например адресование зависимостей: group из мавена есть, а artefact заменен на module. Зачем? Ответа я не нашел.
— динамическое название тасок.
— скорость. это отдельный момент. но жаловатся смысла нет — лучше не будет все равно из-за особенностей всей системы.
— apply plugin statement. Допустим, я вижу такую строчку. Что я должен из него понять. Что плагин добавляет в функционал? Найти доки или исходный код одним кликом — не получится
— productFalvour и buildType — это не просто логические сущности. Каждая из них — это отдельные воркфлоу со своими compile тасками.
— непростой подход к зависимостям между тасками. Чтобы вставить что-то после перед compile, пришлось напрячься.
— про документацию я думаю я много не скажу. Потому что ни разу ответа там на свой вопрос я не нашел. Все нашлось на stackoverflow. И это плохо. Потому что сигнализирует о том, что напрямую из документации вывести ответ не всегда возможно.
— конкретный момент про android. интеграция с NDK — экспериментальная. много пришлось допиливать.
Возможно, написал я не все или не то, о чем справшивалось. Но теперь сухой остаток:
Нравится? Пользуйтесь. А мне проще было бы в другой системе. Да, я сделал все что мне надо было. Но при этом gradle бесполезно потратил мое время.
А общество само сделает свой выбор и без меня. Напомню, что появилась эта штука 9 лет назад. Мавену, между прочим, всего 11.
в мавене используется xml — из-за этого есть жесткая схема действия, выпрыгнуть из неё тяжело, проще сделать по конвенции.
там же в плагинах используются mojo — из-за аннотаций можно взглянув на плагин построить схему конфигурации, её тэги и возможные значения.
я не спорю — всему можно научится. но я умею пользоваться мавеном, его возможностей мне хватает.
авторы гредла, насколько я понимаю, увидели в мавене фатальный недостаток. и запилили свой dsl. это конечно, шутка.
реальная цель было объединить все возможные источники артефактов и билд-систем: maven, ivy, gant.
Но реализация подкачала, на мой взгляд. И не сможет объединить это все, а просто встанет рядом. (тут надо бы картинку про 15 стандартов вставить)
вот чего я не понимаю в грэдл («не понимаю» — в смысле не понимаю зачем авторы взяли такой подход):
— это groovy cо своим dsl. Почему groovy? Ладно, бог с ним, просто у автором в тот момент это было модным. В итоге статической проверки скрипта у нас нет. с синтаксисом тоже трудности. Вот есть блок (фигурные скобки). Это может быть просто блок. А может быть функция-параметр к предыдущей функции.
— gradle wrapper. мне тут трудно комментировать. я бы сделал один корневой тул, устанавливал бы его в систему и расширял плагинами. как в принципе и работает мавен. и даже ант себя с собой не таскает. Тут проблема именно в том, что gradle — это язык, и чтоб не пострадала обратная зависимость — «все свое ношу в собой».
— некоторые термины. например адресование зависимостей: group из мавена есть, а artefact заменен на module. Зачем? Ответа я не нашел.
— динамическое название тасок.
— скорость. это отдельный момент. но жаловатся смысла нет — лучше не будет все равно из-за особенностей всей системы.
— apply plugin statement. Допустим, я вижу такую строчку. Что я должен из него понять. Что плагин добавляет в функционал? Найти доки или исходный код одним кликом — не получится
— productFalvour и buildType — это не просто логические сущности. Каждая из них — это отдельные воркфлоу со своими compile тасками.
— непростой подход к зависимостям между тасками. Чтобы вставить что-то после перед compile, пришлось напрячься.
— про документацию я думаю я много не скажу. Потому что ни разу ответа там на свой вопрос я не нашел. Все нашлось на stackoverflow. И это плохо. Потому что сигнализирует о том, что напрямую из документации вывести ответ не всегда возможно.
— конкретный момент про android. интеграция с NDK — экспериментальная. много пришлось допиливать.
Возможно, написал я не все или не то, о чем справшивалось. Но теперь сухой остаток:
Нравится? Пользуйтесь. А мне проще было бы в другой системе. Да, я сделал все что мне надо было. Но при этом gradle бесполезно потратил мое время.
А общество само сделает свой выбор и без меня. Напомню, что появилась эта штука 9 лет назад. Мавену, между прочим, всего 11.
чуть в сторону про «gradle wrapper» — для Maven тоже есть свой Wrapper и даже два. И решают они как раз таки проблему, которой не должно быть — в зависимости от версии сборщика, может не выполниться сборка или выполниться, но не так, как ожидается. Про их поддержку в IDEA даже issue заведён.
ЗЫ: для gradle, как и для Maven, Wrapper не является необходимым — можно так же скачать ручками и прописать в окружение. Или вы про поддержку сборщика сразу в IDE?
ЗЫ: для gradle, как и для Maven, Wrapper не является необходимым — можно так же скачать ручками и прописать в окружение. Или вы про поддержку сборщика сразу в IDE?
про враппер — я пользовался разными системами, в том числе cmake, maven, ant, msbuild и уже не помню чем. почти везде это был файл. ну два-три, если с настройками. но все это относилось к проекту.
и был очень удивлен, что кроме собственно проектных gradle-файлов мне понадобилось таскать с собой в проекте и все окружение build системы. даже если это всего два файла. это для меня как бы сигнал о том, что за столько времени у gradle есть проблемы со стабильностью (не в смысле падений) до такой степени, что лучше все с собой таскать на всякий случай.
ну вот, узнал, что для мавена тоже есть врапперы. за 7 лет ни разу он не понадобился. в gradle — понадобился мгновенно.
и был очень удивлен, что кроме собственно проектных gradle-файлов мне понадобилось таскать с собой в проекте и все окружение build системы. даже если это всего два файла. это для меня как бы сигнал о том, что за столько времени у gradle есть проблемы со стабильностью (не в смысле падений) до такой степени, что лучше все с собой таскать на всякий случай.
ну вот, узнал, что для мавена тоже есть врапперы. за 7 лет ни разу он не понадобился. в gradle — понадобился мгновенно.
покажите пример, где для запуска Maven проекта не понадобится «два файла» или же предварительно установленной внешней build-софтины. Т.е. я к тому, что я не вижу в этом разницы между Gradle и Maven. И это не считая требования к наличию установленной JDK
в пустом мавен проекте у меня всего лишь pom.xml
в гредл — 8:
и это рекомендуется добавить в vcs.
https://docs.gradle.org/current/dsl/org.gradle.api.tasks.wrapper.Wrapper.html
Причина следующая:
я не евангелист мавена, я просто не проникся гредлом по многим причинам. я за маленькие, чистые, быстрые и простые инструменты, которые не являются вещью в себе
в гредл — 8:
./gradle/wrapper/gradle-wrapper.properties
./gradle/wrapper/gradle-wrapper.jar
./gradle.properties
./gradlew.bat
./settings.gradle
./gradlew
./.gradle
./build.gradle
и это рекомендуется добавить в vcs.
https://docs.gradle.org/current/dsl/org.gradle.api.tasks.wrapper.Wrapper.html
Причина следующая:
Most tools require installation on your computer before you can use them. If the installation is easy, you may think that’s fine. But it can be an unnecessary burden on the users of the build. Equally importantly, will the user install the right version of the tool for the build? What if they’re building an old version of the software?
The Gradle Wrapper (henceforth referred to as the “Wrapper”) solves both these problems and is the preferred way of starting a Gradle build.
я не евангелист мавена, я просто не проникся гредлом по многим причинам. я за маленькие, чистые, быстрые и простые инструменты, которые не являются вещью в себе
в пустом Gradle проекте у меня тоже ровно один файл — build.gradle.
Каталог "$PROJECT_DIR$/.gradle" будет создан после запуска — его можно не класть никуда.
Каталог "$PROJECT_DIR$/gradle/wrapper" и файлы "$PROJECT_DIR$./gradlew*" — это файлы от Wrapper. не хотите — не создавайте и тогда получите то же, что и с Maven — требование предварительной установки Gradle в окружение запуска
файлы "$PROJECT_DIR$/gradle.properties" и "$PROJECT_DIR$/settings.gradle" — это дополнительные настройки для проекта. Ровно так же, как и для Maven это "$PROJECT_DIR$/.mvn/extensions.xml", "$PROJECT_DIR$./.mvn/maven.config" и "$PROJECT_DIR$./.mvn/settings.xml".
Каталог "$PROJECT_DIR$/.gradle" будет создан после запуска — его можно не класть никуда.
Каталог "$PROJECT_DIR$/gradle/wrapper" и файлы "$PROJECT_DIR$./gradlew*" — это файлы от Wrapper. не хотите — не создавайте и тогда получите то же, что и с Maven — требование предварительной установки Gradle в окружение запуска
файлы "$PROJECT_DIR$/gradle.properties" и "$PROJECT_DIR$/settings.gradle" — это дополнительные настройки для проекта. Ровно так же, как и для Maven это "$PROJECT_DIR$/.mvn/extensions.xml", "$PROJECT_DIR$./.mvn/maven.config" и "$PROJECT_DIR$./.mvn/settings.xml".
Да, фактически большинство из того что вы описали или вкусовщина, или то что будет допилено (NDK например).
Скорость больное место, но с выходом давнишней 2.4 уже не настолько, да и существенно быстрее времён Eclipse/Ant.
+ из того что я нагуглил Gradle 2 годичной давности якобы быстрее Maven.
Документация на самом деле отличнейшая, другое дело что она огромна)
В целом я не могу с вам согласится, но безусловно вы можете быть правы и хорошо оно есть)
Скорость больное место, но с выходом давнишней 2.4 уже не настолько, да и существенно быстрее времён Eclipse/Ant.
+ из того что я нагуглил Gradle 2 годичной давности якобы быстрее Maven.
Документация на самом деле отличнейшая, другое дело что она огромна)
В целом я не могу с вам согласится, но безусловно вы можете быть правы и хорошо оно есть)
Как-то я сразу не заметил часть вашего комментария, дополню:
> Напомню, что появилась эта штука 9 лет назад. Мавену, между прочим, всего 11.
Я не скажу когда конкретно началась alpha разработка Gradle(насколько помню в 2008), но первый релиз был в 2012. Maven 1 релиз был в 2002/2004 (честно не помню), Maven 2 в 2005.
> Напомню, что появилась эта штука 9 лет назад. Мавену, между прочим, всего 11.
Я не скажу когда конкретно началась alpha разработка Gradle(насколько помню в 2008), но первый релиз был в 2012. Maven 1 релиз был в 2002/2004 (честно не помню), Maven 2 в 2005.
Ну, первые RC (версии 0.9) появились в 2010, а вообще и раньше были версии.
https://services.gradle.org/distributions
Но это и не так важно. У нас всех есть уникальный шанс посмотреть во что это выльется. У меня лично есть шанс послушать фанатиков с горящими глазами. Сегодня у них горит грэдл, завтра будет что-нибудь другое. Буду ждать интересные продукты.
https://services.gradle.org/distributions
Но это и не так важно. У нас всех есть уникальный шанс посмотреть во что это выльется. У меня лично есть шанс послушать фанатиков с горящими глазами. Сегодня у них горит грэдл, завтра будет что-нибудь другое. Буду ждать интересные продукты.
UFO just landed and posted this here
попробуйте Gradle без демона запускать и с предварительной очисткой. Вы же Maven тоже с clean запускаете?
опишите подробнее — какие операции мавена занимали 10 минут?
UFO just landed and posted this here
немного сумбурно, не могу уловить где теряется 10 минут.
1. у вас netbeans копируется в target 10 минут, я правильно понял?
2. вы разбирались почему отсутствие clean ломает сборку?
3. какому-то плагину надо скопировать netbeans. какому?
1. у вас netbeans копируется в target 10 минут, я правильно понял?
2. вы разбирались почему отсутствие clean ломает сборку?
3. какому-то плагину надо скопировать netbeans. какому?
UFO just landed and posted this here
но мавен можно винить за то, что у меня в нем нет возможности ничего затюнитьнеправда ваша. Каждый этап выполнения можно затюнить так, как вам хочется. Открываете полный жизненный цикл, и для каждого этапа есть соответствующий плагин. Например, для этапа «process-resources» используется плагин maven-resource-plugin
А ещё, там же, в доке по жизненному циклу, указаны какие этапы будут явно вызваны для разных типов сборки
В грэдле я довольно легко сделал так, чтобы такого перекладывания не происходило
Ну так настройте ресурсы так, чтобы он их тянул оттуда же. читайте про настройку плагина maven-resources-plugin
Собрать надо, а паковать не обязательноэто как?
Но плугин мавена мне не позволяет вырубить ненужный шагой, да ладно? практически у каждого плагина есть свойство skip — воспользуйтесь.
В общем, вы не пробовали документацию получше почитать про Maven?
В gradle намного лучше устроена паралелизация процессов для модулей + включенный демон творит чудеса. Поэтому сборка на gradle всегда быстрее, особенно если всё настроить.
Лично у меня maven запускается через Jenkins, и там между одной минутой, пятью или получасом не сильно большая разница. Очень редко бывает так, что проект собирается в IDE но не собирается в Maven. Когда проект собирается в IDE (Eclipse, у некоторых разработчиков в IDEA), то собирается он инкрементально в считанные секунды. Вот и спрашивается: нафига в системах сборки меряться секундами?
UFO just landed and posted this here
Реквестирую холивар. Почему основным сделали Gradle, а не Maven? ИМХО, хоть в Maven есть недостатки, он всяко лучше Gradle с его Тьюринг-полным DSL.
Как программировать на XML? Писать на каждый чих плагин?
Конечно, Groovy далеко не лучший язык, да и Gradle его лучше не делает, но это всё же гораздо гибче XML. + Gradle Wrapper офигенная штука.
Конечно, Groovy далеко не лучший язык, да и Gradle его лучше не делает, но это всё же гораздо гибче XML. + Gradle Wrapper офигенная штука.
Поддерживаю. Для меня gradle+Groovy стал на столько удобно и главное — гибко, что maven быстро ушел на антресоли истории.
Зачем программировать в системе сборки? Что это за чих такой, где не хватает имеющихся плагинов Maven? Хотя бы один пример можно?
Есть одна интересная проблема с Тьюринг-полными DSL. Maven даёт очень хорошую фичу: проект одинаково хорошо открывается в любой IDE без дополнительных настроек. Этому очень помогает декларативная природа XML. Groovy, как язык, подверженный проблеме останова, не может обеспечить того же в общем случае.
Вот пример: взял я и добавил maven-checkstyle-plugin. Открываю проект в IDEA или Eclipse и мне уже не надо настраивать правила checkstyle в этих IDE — они сами считают их из pom.xml. Как такое сделать в gradle? А что если я напишу скрипт на groovy, который итерирует по модулям проекта хитрым образом, находит в них какой-нибудь properties-файл и на основе настроек в нём включает/выключает checkstyle с тем или иным набором правил? Как IDE распарсит такой скрипт? Выполнит его, т.е. фактически начнёт собирать проект не сама а через gradle? Опять же, если непонятно, почему это плохо, спрашивайте, я напишу в ответ, просто долго перечислять причины.
Есть одна интересная проблема с Тьюринг-полными DSL. Maven даёт очень хорошую фичу: проект одинаково хорошо открывается в любой IDE без дополнительных настроек. Этому очень помогает декларативная природа XML. Groovy, как язык, подверженный проблеме останова, не может обеспечить того же в общем случае.
Вот пример: взял я и добавил maven-checkstyle-plugin. Открываю проект в IDEA или Eclipse и мне уже не надо настраивать правила checkstyle в этих IDE — они сами считают их из pom.xml. Как такое сделать в gradle? А что если я напишу скрипт на groovy, который итерирует по модулям проекта хитрым образом, находит в них какой-нибудь properties-файл и на основе настроек в нём включает/выключает checkstyle с тем или иным набором правил? Как IDE распарсит такой скрипт? Выполнит его, т.е. фактически начнёт собирать проект не сама а через gradle? Опять же, если непонятно, почему это плохо, спрашивайте, я напишу в ответ, просто долго перечислять причины.
Выполнит его, т.е. фактически начнёт собирать проект не сама а через gradle? Опять же, если непонятно, почему это плохо, спрашивайте, я напишу в ответ, просто долго перечислять причины.Да, к сожалению. Именно этим меня дико раздражал gradle при использовании idea + auto import, т. к. на каждое изменение в build.gradle идея начинала тормозить, обновляя проект на основе выполнения build.gradle.
IDE которая работает с Gradle никогда не собирает проект сама, она банально отдаёт всю работу по созданию сборке – системе сборки. И это замечательно, ваша сборка на билд сервере и в вашей IDE будет идентичной (если мы исключим варианты с конфигурацией Gradle на обоих машинах), в любом случае проблем становиться на много меньше.
По этому идеологически верно что система сборки отдельно, IDE отдельно. И checkstyle подключаемый в gradle не должен автоматически влиять на IDE. При сильном желании это может происходить через интеграцию, но это уже другая тема.
По этому идеологически верно что система сборки отдельно, IDE отдельно. И checkstyle подключаемый в gradle не должен автоматически влиять на IDE. При сильном желании это может происходить через интеграцию, но это уже другая тема.
И это замечательно, ваша сборка на билд сервере и в вашей IDE будет идентичной (если мы исключим варианты с конфигурацией Gradle на обоих машинах), в любом случае проблем становиться на много меньше.
И это просто ужасно! Если в том же Eclipse я хочу, чтобы проект собрался один-в-один, как на билд-сервере, я создам run configuration типа maven build и буду использовать его. Но это реально не так часто нужно. А 99% времени я не собираю проект, а пишу код и перезапускаю его. В этом смысле мне очень нравится подход Eclipse, который вообще ничего не собирает при запуске приложения: ведь код уже скомпилирован, пока я его писал, и все class-файлы лежат на своих местах. В 1% случаев я после недель кодирования отдаю код на тестирование, т.е. мне надо убедиться, что он нормально развернётся на тестовом сервере. Вот тогда я могу прогнать maven build (опять же, из IDE). Хотя на самом деле я вручную этого не делаю — если что, Jenkins мне напишет.
И checkstyle подключаемый в gradle не должен автоматически влиять на IDE
Почему checkstyle не должен влиять на IDE? Зачем я вообще подключаю checkstyle? Чтобы он мне помогал мне делать ревью. Но опять же, если разработчики оперативно получают информацию от IDE, что их стиль кодирования не пройдёт ревью, они сразу исправят ошибки, вместо того, чтобы меня засыпать кучей глупых ошибок с шириной отступа или забытыми пробелами. Наконец, непонятно, почему чтобы запустить проект, я должен каждый раз прогонять checkstyle?
При сильном желании это может происходить через интеграцию
Так интеграция всяко гораздо лучше, если плагин к IDE общается непосредственно с checkstyle, чем если он парсит вывод плагина к системе сборки.
Уже прошло года 3-4 с тех пор как я открывал Eclipse. Возможно сейчас всё изменилось (тот же Gradle плагин написали для Eclipse), но тогда всё было очень плохо во многих местах, если говорить про Android разработку естественно.
«Если в том же Eclipse я хочу, чтобы проект собрался один-в-один, как на билд-сервере, я создам run configuration типа maven build и буду использовать его.»
А тут даже делать ничего не нужно.
Так плагин вы подключаете к build system или к IDE? С тем же checkstyle я не вижу проблемы т.к. у вас есть возможность как установить плагин к IDE отдельно, так и установить плагин к Gradle и интеграцию к IDE.
«Если в том же Eclipse я хочу, чтобы проект собрался один-в-один, как на билд-сервере, я создам run configuration типа maven build и буду использовать его.»
А тут даже делать ничего не нужно.
Так плагин вы подключаете к build system или к IDE? С тем же checkstyle я не вижу проблемы т.к. у вас есть возможность как установить плагин к IDE отдельно, так и установить плагин к Gradle и интеграцию к IDE.
Так плагин вы подключаете к build system или к IDE? С тем же checkstyle я не вижу проблемы т.к. у вас есть возможность как установить плагин к IDE отдельно, так и установить плагин к Gradle и интеграцию к IDE.
Так дело-то в том, что в случае с maven я ставлю плагин к m2e, который умеет конфигурировать эклипсовский плагин checkstyle согласно настройкам в pom.xml. Без этого плагина как получается: если к проекту присоединяется человек, ему нужно вычитать мануал по настройке eclipse, чтобы выполнить по нему достаточно непростой квест, ведь такой мануал, как водится, постоянно устаревает. Если настройки проекта меняют, опять же, нужно научить всю команду эти настройки поменять. Теперь как это выглядит с коннектором m2e: ответственный человек меняет настройки в pom.xml и они сами расползаются в IDE разработчиков.
ну так берите и конфигурите gradle проект так же, как вы это делаете с конфигурированием Maven проекта: docs.gradle.org/current/userguide/eclipse_plugin.html
Maven проект я не так конфигурирую. Когда-то так было, да, но теперь Eclipse перешёл на концепцию коннекторов m2e. Думаю, не случайно они так поступили, видимо, были какие-то подводные камни. Могу предположить следующее: от версии к версии плагины Eclipse могут менять формат своей конфигурации, поэтому очень сложно обеспечить совместимость конфигурации, сгенерённой инструментом сборки с актуальными версиями плагинов IDE.
Мне всё же непонятно, как можно конфигурацию gradle перевести в конфигурацию IDE. С XML понятно, как: тут полностью декларативный язык, который можно один-в-один переносить в конфигурацию. Gradle использует groovy, единственный способ который правильно «распарсить» — это исполнить скрипт, и тут в полный рост становится проблема останова.
Мне всё же непонятно, как можно конфигурацию gradle перевести в конфигурацию IDE. С XML понятно, как: тут полностью декларативный язык, который можно один-в-один переносить в конфигурацию. Gradle использует groovy, единственный способ который правильно «распарсить» — это исполнить скрипт, и тут в полный рост становится проблема останова.
Невозможно добавить в IDE поддержку всех плагинов, а есть настройки плагинов, которые влияют на сборку, поэтому сборка может быть точно воспроизведена только системой сборки для которой она сконфигурирована. Я в этом уже несколько раз убеждался. Единственный способ сделать так, чтобы сборка в IDE не отличалась от сборки из консоли, это использовать тот минимум функционала, что поддерживает IDE, но кому такой обрубок нужен? Декларативность pom не панацея ни разу.
чихи разные бывают. Для каких-то достаточно просто правильно настроить плагин, а для каких-то да, придётся писать свой.
Пример чиха, пожалуйста, в студию.
два в одном: habrahabr.ru/post/205118
в начале под спойлером чих без плагина, а потом чих с написанием плагина для того же
в начале под спойлером чих без плагина, а потом чих с написанием плагина для того же
Ну в данном случае достаточно было стандартных средств maven. Я не говорю, что maven идеален, я говорю лишь про то, что maven в итоге — меньшее зло (почему gradle большее зло, за меня очень хорошо написал GubkaBob здесь). И вообще, непонятно, что за такая задача, в которой нужно копировать shared-библиотеки и перезапускать tomcat. Тем более, как это относится к сборке проекта?
Что бы сравнивать нужно определить критерии, а чем лучше?
Если сравнить по базовым концепциям систем сборок то Maven не является полноценной декларативной системой сборки, Gradle является.
Если сравнить по базовым концепциям систем сборок то Maven не является полноценной декларативной системой сборки, Gradle является.
Если сравнить по базовым концепциям систем сборок то Maven не является полноценной декларативной системой сборки, Gradle является.
Вот про это пожалуйста подробнее. Что за концепции и почему Maven не является полноценной?
Этот комментарий при детальном ответе мог бы перейти в небольшую статью, но буду краток.
Ключевой точкой любой системы сборки является Execution Units(Gradle: task, Maven: goal && lifecycle) + Execution Dependencies (Gradle: dependsOn, Maven: goal dependencies && lifecycle).
Собственно Control Flow (порядок выполнения) состоит из Execution Units + Executuin Dependencies. Ни одна система сборки не может существовать без Control Flow. И в императивной системе сборки Build Author полностью определяет Control Flow т.е. определяем абсолютно все значения и всегда весь порядок. Чистейшим примером императивной системы сборки является Ant.
Декларативная система сборки отличается тем что Build Author может не определять Control Flow, например когда вы подключаете в Gradle плагин вы автоматически получите Control Flow и необходимые таски плагина будут выполнены. В Gradle это называется декларативными элементами верхнего уровня.
В Maven так же есть возможность подключить плагин, но это делается на императивном уровне т.е. всё равно происходит привязка плагина к фазе сборки проекта. Например возьмем кусок настройки подключения плагина из статьи Borz
Кроме этого концепция плагинов в Gradle и Maven абсолютно отличается.
Кроме того в Gradle есть декларативные элементы нижнего уровня, которых в Maven просто нет.
Т.е. для того что бы переопределить какой-то конкретный элемент для конкретного варианта сборки нам не нужно определять/переопределять Control Flow.
Ключевой точкой любой системы сборки является Execution Units(Gradle: task, Maven: goal && lifecycle) + Execution Dependencies (Gradle: dependsOn, Maven: goal dependencies && lifecycle).
Собственно Control Flow (порядок выполнения) состоит из Execution Units + Executuin Dependencies. Ни одна система сборки не может существовать без Control Flow. И в императивной системе сборки Build Author полностью определяет Control Flow т.е. определяем абсолютно все значения и всегда весь порядок. Чистейшим примером императивной системы сборки является Ant.
Декларативная система сборки отличается тем что Build Author может не определять Control Flow, например когда вы подключаете в Gradle плагин вы автоматически получите Control Flow и необходимые таски плагина будут выполнены. В Gradle это называется декларативными элементами верхнего уровня.
apply plugin: 'com.android.application'
В Maven так же есть возможность подключить плагин, но это делается на императивном уровне т.е. всё равно происходит привязка плагина к фазе сборки проекта. Например возьмем кусок настройки подключения плагина из статьи Borz
<plugin>
<artifactId>maven-dependency-plugin</artifactId>
<executions>
<execution>
<phase>package</phase>
<goals>
<goal>copy-dependencies</goal>
</goals>
<configuration>
<useSubDirectoryPerScope>true</useSubDirectoryPerScope>
<excludeGroupIds>исключаем некоторые группы, попадающие в war-архив</excludeGroupIds>
</configuration>
</execution>
</executions>
</plugin>
Кроме этого концепция плагинов в Gradle и Maven абсолютно отличается.
Кроме того в Gradle есть декларативные элементы нижнего уровня, которых в Maven просто нет.
sourceSets {
integTest {
java.srcDir file('src/integration-test/java')
resources.srcDir file('src/integration-test/res')
compileClasspath = sourceSets.main.output + configurations.integTest
runtimeClasspath = output + compileClasspath
}
}
Т.е. для того что бы переопределить какой-то конкретный элемент для конкретного варианта сборки нам не нужно определять/переопределять Control Flow.
не совсем так. так же, как и в Gradle, в Maven я мог бы просто указать
а потом, просто вызвать «mvn package» и тогда на этапе process-sources вызвался бы goal copy-dependencies. Но, т.к. мне необходимо, чтобы он вызвался на этапе package, я явно прописываю необходимую фазу для этого goal. В Gradle это равносильно «build.dependsOn copy-dependencies», как я понимаю
Существенное отличие Gradle (кому плюс, кому минус) в том, что имеется возможность перенастроить последовательность, а то и вовсе исключить шаги из жизненного цикла — в Maven с этим довольно сложно, хотя и, при большом желании, можно.
<plugin>
<artifactId>maven-dependency-plugin</artifactId>
</plugin>
а потом, просто вызвать «mvn package» и тогда на этапе process-sources вызвался бы goal copy-dependencies. Но, т.к. мне необходимо, чтобы он вызвался на этапе package, я явно прописываю необходимую фазу для этого goal. В Gradle это равносильно «build.dependsOn copy-dependencies», как я понимаю
Существенное отличие Gradle (кому плюс, кому минус) в том, что имеется возможность перенастроить последовательность, а то и вовсе исключить шаги из жизненного цикла — в Maven с этим довольно сложно, хотя и, при большом желании, можно.
Читая про сложности с управлением версиями зависимостей всё ждал, когда же вы про этот плагин напишете. Не дождался.
А как понять в каких зависимостях используется GwtCompatible, как то не очевидно это из сообщения об ошибке?
Sign up to leave a comment.
Gradle: управляя зависимостями