Комментарии 21
Спасибо. Полезная статья
Точно так же как профилировать любое другое приложение на Java? И еще есть gradle build --scan
В статье https://developer.android.com/studio/build/profile-your-build рекомендуют использовать "gradle-profiler" или "gradlew --profile". Так же рекомендуют использовать Build Analyzer https://developer.android.com/studio/build/build-analyzer, по сути, графический вариант gradlew --profile
Я боюсь использовать gradle не из-за groovy dsl, а из-за того что каждый мажорный релиз в нем меняется формат конфигурации, и все гайды со stackoverflow перестают работать. Нельзя просто настроить и забыть, в отличие от великолепного во всех отношениях maven.
Если что-то устареет в новом мажорном релизе, то на протяжении всего предыдущего мажорного релиза в консоли указывается на выражение в вашем скрипте которое станет deprecated, то есть ещё продержится целый релиз. А если что-то удаляют, то оно будет помечено deprecated весь прошлый мажорный релиз. Это касается оф. дистрибутива Gradle и оф плагинов. С внешними плагинами все сложнее. и как правило они перестают работать в мажорном релизе без обновления своей версии. Интересно посмотреть на пример внезапного изменения официального dsl без уведомления пользователя в прошлой версии. В Gradle высокий уровень вхождения, однако, когда осознаешь, как оно работает, то можно творить чудеса со сборкой.
В каких всех отношениях то... Тонна тегов и бесполезного текста, огромные структуры, в которых легко запутаться. Кошмар одним словом.
Большое спасибо, полезно
Отличная статья.
А вот тут нет опечатки?
"Теперь вы можете указать в подпроекте implementation("org.apache.commons:commons-lang3:3.5"), если не ни один тип или метод из commons-lang не станет частью публичного API. "
Не хватает сравнения с maven и не на hello world
Так же забыли рассказать про, его кеширование и "чудо" работу со snapshot зависимостями и refresh библиотек
Про разные синтаксис конфигов для java и kotlin, вот зачем это устроили...
Про глюки с maven репой локальной и прочими граблями, когда не находит библиотеки
И в чем же его плюс?
Я извиняюсь, а что не так с кэшированием?! Точнее, какое именно кеширование вас не устраивает?
И вот уж в работе с зависимостями, maven с gradle - даже "рядом не стоял", как говориться. Как их вообще можно сравнивать в этом аспекте?! Maven в некоторые вещи же не умеет в принципе.
Что есть "refresh библиотек"?
Про "разные синтаксис конфигов для java и kotlin" - вообще не понял. Это вы про groovy vs kotlin script, чтоль? Ну разные языки - разный синтаксис. Но, что groovy, что kts можно использовать как с java, так и с kotlin проектами. kts вариант - как чуть более строгий - чуть более громоздкий.
Я с gradle работаю с 3й его версии... и - честно говоря - хоть какие-то "глюки" с использование mavenLocal могу припомнить как раз только в "тройке". Если вы о чем-то конкретном - так расскажите, а то вдруг "мужики-то не знают".
P.S. Вынуждено использую по работе и maven тож... гораздо более часто, чем мне хотелось бы. Имхо, у maven (перед gradle) есть единственное преимущество... оно выражается в принципе: "безобразно, зато единообразно".
Про кеши и refresh библиотек, особенно обратите внимание на количество голосов https://stackoverflow.com/questions/13565082/how-can-i-force-gradle-to-redownload-dependencies
"разные синтаксис конфигов для java и kotlin"
Например для Java это
implementation group: 'org.apache.calcite', name: 'calcite-core', version: '1.32.0'
или коротко
implementation 'org.apache.calcite:calcite-core:1.32.0'
а для котлина
implementation("org.apache.calcite:calcite-core:1.32.0")
Ну вот зачем делать по разному то? Это мелочи, но все это удобство использования...которого нет
Глюки я порядком следования реп
mavenCentral()
mavenLocal()
maven {
name = "repo-snapshots"
url = uri("https://repo.....ru/repository/snapshots/")
}
если я на первое место поставлю mavenLocal(), то все сломается, будет писать о том, что не нашла библиотеку такуюто....
я ожидал, что она посмотрит это в mavenLocal(), а если там нет, то пойдет дальше в mavenCentral(), но этого она не делает.
Плюсы то Gradle какие? озвучьте
Про кеши и refresh библиотек, особенно обратите внимание на количество голосов https://stackoverflow.com/questions/13565082/how-can-i-force-gradle-to-redownload-dependencies
И что я тут должен увидеть?! Что большинство из тех, кто поставил "плюсики" не могут не то, что в RTFM, но и в банальный
gradlew --help
?
"разные синтаксис конфигов для java и kotlin"
Это не для "Java и Kotlin". Это groovy и kotlin script. В том смысле, что - независимо от - вы можете описывать скрипты gradle либо на groovy, либо на kts. Языки эти (groovy и kotlin) разные... синтаксис у них тоже разный. Но, и на groovy писать "со скобочками" вам никто не запрещает :-)
Глюки я порядком следования реп
Очень странное у вас. Специально у себя проверил - нет такого. Поискал в issue - тож нет ничего про "порядок". В доках есть про то, что не желательно ставить mavenLocal первым... но по другой причине. Какая хоть версия gradle используется?
Плюсы то Gradle какие? озвучьте
Лично для меня, главное преимущество gradle на maven - это работа с зависимостями и разрешение их конфликтов.
Второе - это работа с multi-module проектами. Так-то оно вроде как и не сильно отличается. На первый взгляд. Но - как говорится - "есть нюансы". Которые чем больше "мульти", тем сильнее раздражают в maven.
про кеши, вот есть у вас связанный проект, собрали его, положили как snapshot с какой то версией, в основном проекте подключили как зависимость собрали, тут все отлично. Но дальше начинаются приколы, я начинаю дорабатывать локально зависимую библиотеку, я вынужден каждый ребилд инкрементировать версию, если хочу сразу проверить в основном проекте, так как делать то, что написано по ссылке со стековерфлоу это треш не быстрый с кучей последствий.
а зачем мне делать инкремент библиотеки, если реально она еще не отлажена?Понятно, что тут можно сказать, пишите больше интеграционных тестов в проекте библиотеки, а потом только инкрементируйте версию, но жизнь немного сложнее. Поэтому кроме инкремента версии snapshot я не нашел ни одного способа обновить закешированную библу в основном проекте... Поэтому тот топик не про gradlew --help. И у такого подхода есть куча проблем, когда двое начнут это делать параллельно :).
версия градл 6.9.2 на которой все эти глюки и происходят, с кешем у всех членов команды, с репами у меня, на маке. В итоге подвинул local на последнее место..
Все что мне необходимо от средства сборки это стабильно собирать проект от версии к версии.
А с зависимостями чем мавен не угодил?
И лучше не перебарщивать со сложностью зависимостей, модулей и сложностью сборки, серверные мульти модульные проекты на мавене норм, но да могут быть нюансы, но и в градле их не меньше... Чем сложнее у вас проект по зависимостям тем хуже продумана архитектура - все гениальное просто.
По итогу глюков в градле больше, а бенефит ...
Я извиняюсь, но вы рассказываете какие-то "чудеса"... либо мне "везет 10 лет подряд", либо вам "жутко не везет". Но, за все время, что я использую gradle, я не помню каких-либо проблем со snapshot'ами :-(
Если вы "локально дорабатываете"... и как-то так получилось, что вы не можете дать версии "суффикс" -SNAPSHOT, то:
В чем проблема пробрасывать эту зависимость через mavenLocal? Он, собственно, исключительно для этого "придуман", и артефакты из него не кэшируются в принципе.
Если это нужно не только вам (т.е. надо "пробрасывать" через внешний репозиторий), то в чем проблема настроить этот репозиторий именно как snapshot репозиторий?
Если это не snapshot репозиторий (там "всё в кучу") в чем проблема описать версию этой зависимости как, например, latest.release? Ну и указать что dynamic versions обновлять, так часто, как вам удобно.
Ну и если это не устраивает - то можно тогда "руками" объявить "прям именно вот эту" зависимость как changing. Ну и да... прописать, насколько часто вы хотите обновлять changing.
Поэтому кроме инкремента версии snapshot я не нашел ни одного способа обновить закешированную библу в основном проекте...
Их реально - "на все случаи жизни"... какого-то одного "правильного" способа - нет. Про все это - так или иначе - есть в официальной документации.
версия градл 6.9.2 на которой все эти глюки и происходят, с кешем у всех членов команды, с репами у меня, на маке. В итоге подвинул local на последнее место..
Прям вообще странно :-( Можно было бы предположить, что у вас - возможно - какой-то "странный maven"... или, например, "нестандартный" packaging используется. Но оно - в любом случае - не должно ограничиваться только mavenLocal.
"По фотографии" можно попробовать явно прописать источник метаданных для mavenLocal... например:
mavenLocal() {
metadataSources {
mavenPom()
artifact()
}
}
и посмотреть
а так... еслиб у вас был минимальный воспроизводимый пример - яб с удовольствием глянул.
Все что мне необходимо от средства сборки это стабильно собирать проект от версии к версии.
:-) Вы точно про maven? Лично у меня вот, система, в которой резолвинг зависит от позиции зависимости, особого доверия не вызывает :-) После того, как несколько раз было "больно" - я к этому весьма "трепетно" отношусь :-) По факту - единственный способ гарантированно добиться в maven того, что вы хотите, это явно перечислить все (и транзитивные) зависимости на уровне модуля. Только это дает гарантию, что из-за того, что кто-то в "паренте" не поменял местами "два тэга", у вас теперь не "все плохо".
А с зависимостями чем мавен не угодил?
Если совсем "коротко и о больном" - оно не умеет в dynamic. Точнее, говорит, что умеет, но тут же уточняет, что "лучше не надо" :) И когда пробуешь, понимаешь, что действительно - "не надо"
А у gradle с этим - ну... не скажу что всем прям идеально... но прям сильно лучше. И у него своя модель для. Более логичная, имхо. Но и вариант с maven'овским -SNAPSHOT он умеет поддерживать.
По итогу глюков в градле больше, а бенефит ...
По итогу, "глюков" у меня нет не в gradle, не в maven. Все работает "как и задумано". Другое дело, что как "задумано" в maven - порой - скажем так, сильно удивляет :-)
P.S. Мне эти "войны" сильно напоминают те, что шли - в свое время с git'ом. "Интенсивность", конечно, далеко не та... но "смысл" вот прям сильно напоминает :-)
В Gradle можно погрузиться, достичь просветления и творить чудеса.
Вот только остальная команда потом офигевает с написанных портянок, где всё вперемешку и творится какая-то магия, которую никто кроме автора не понимает. А чтобы что-то поменять, надо посидеть и сначала разобраться, что там за хрень вообще происходит.
По моему опыту нестрогость подхода в сочетании с кучей возможностей делает Gradle похожим скорее на Javascript в его плохих проявлениях. Maven же даёт чёткую структуру и правила, и не позволяет писать внутри себя скрипты (без откровенных костылей), всё описывается декларативно. Конфиги Maven может поддерживать и изменять любой программист в команде, там не образуется легаси.
Это не говоря о том, что очень тормознуто работает подсветка синтаксиса и выпадающие подсказки по коду, особенно если писать билд файл на котлине. Несколько десятков секунд для выпадающей подсказки - так удобно работать не получится.
У Maven конечно свои минусы в виде многословности, часто странной документации. Плюс Gradle классно интегрируется с IDE для сборки проектов.
В Gradle можно погрузиться, достичь просветления и творить чудеса.
По личному опыту - gradle замечательно осваивается и "на минималках"... вот ровно в той же степени, что и maven. В смысле, "вот тут, вот так прописываешь зависимости, а вот тут, вот так - плагины". Опять же - по личному опыту - это вот уровень 90% тех, кто пользует что gradle, что maven. И на этом "уровне владения" разница - исключительное имхо - только в "как задумано". "Задумано" в gradle сильно лучше :-)
Абсолютному большинству "сугубо фиолетово", что gradle - это скрипт, а maven - это декларативно. Как только надо что-то "выходящее за рамки", что в одном случае, что во втором - зовут "больших дядей" :-)
Вот только остальная команда потом офигевает с написанных портянок, где всё вперемешку и творится какая-то магия, которую никто кроме автора не понимает. А чтобы что-то поменять, надо посидеть и сначала разобраться, что там за хрень вообще происходит.
Я вот честно пытаюсь вспомнить, как часто надо было "что-то поменять". Ну вот это прям сильно редко же :-) В подавляющем большинстве случаев, что в pom.xml, что в build.gradle лезут именно за тем, что "вот тут вот, вот так вот прописываются зависимости".
Да - чисто теоретически - в gradle можно сделать так, что "вот тут вот, вот так вот" будет так, что "никто кроме автора не понимает". Можно. Но этож надо специально так хотеть сделать. Нет? В maven - внезапно - если задаться целью, тоже можно "всякое" :-) Почему-то желающих такое делать - сильно не много. Но при этом, превалирует мнение, что вот как только сел за gradle - ух... навертят тут мне... разбирайся потом. Почему - не понятно. Лично я не встречал проектов, где специально делали так, что "никто кроме автора не понимает". Такие, в которых "так само получилось" - встречал. Но я их и в maven встречал... и таки сильно чаще, чем в gradle. Я даже - в свое время - задавался вопросом: "почему так?" Для себя я нашел ответ в том, что если ты сталкиваешься с, условным, "нех" в gradle, ты - в принципе - можешь сесть/почитать/разобраться и таки сделать, то что тебе надо... если не "по канону", то не сильно выходя за рамки. А вот если случилось так, что, условный, "нех" настиг тебя в maven - тут уж "пистолет один ...", как говорится :-) А рано или поздно, но "нех" таки случается.
По моему опыту нестрогость подхода в сочетании с кучей возможностей делает Gradle похожим скорее на Javascript в его плохих проявлениях.
?! У gradle, вполне себе, строгий подход. Другое дело, что он императивный. Т.е. ты - в принципе - отвечаешь на вопрос "как?". Но... т.к. 99.9999% ответов на этот вопрос уже - так или иначе - даны, вся императивность сводится к "выбери из вот этих вариантов". Попытки написать "свое такое же, только лучше" очень быстро сходят на нет. Ну просто потому что: "а в чем смысл?" Свое рождается ровно в двух случаях: либо ты банально не знаешь, что это "уже есть и работает" - и тут на выручку, по идее, приходят "большие дяди"... они же "старшие товарищи"; либо это действительно нужно. Вот сама принципиальная возможность решить проблему "по-человечьи" - она, имхо, таки ценна.
Maven же даёт чёткую структуру и правила, и не позволяет писать внутри себя скрипты (без откровенных костылей), всё описывается декларативно. Конфиги Maven может поддерживать и изменять любой программист в команде, там не образуется легаси.
Ох, еслиб все было так хорошо - никто бы не "страдал" в gradle... ибо, "а в чем смысл?" :-) Да у нас есть xml схема... которая "сама по себе" - внезапно - не умеет вообще ничего. Вдруг выясняется, что весь (практически весь, если совсем точно - и в этом-то вся боль, что не "вообще весь") maven - это "всего лишь" набор плагинов. Просто какие-то входят в "стандартную поставку", а какие-то нет. И с тем, что в "стандартной поставке", вы - внезапно - не покрываете всех своих кейсов. Вы начинаете искать, то что вам надо... и вот так рождаются "maven школы" :-) Я в том смысле, что maven - он же сильно разный, на самом деле. Только структура pom.xml - более менее - "прибита гвоздями". Поэтому, когда вы говорите, что "конфиги Maven может поддерживать и изменять любой программист в команде" - это верно только в той части, которая - я про это писал выше - про "вот тут, вот так прописываем зависимости". Но и даже тут вас подстерегают всякого рода "засады". Так что - это только кажется, что "это просто" и "да любой может". "Просто" в maven только в каких-то вырожденных случаях... которые "в живой природе" встречаются крайне редко... к сожалению.
Тут же можно возразить, что и в gradle плагины же. Но, плагины в gradle это действительно способ "пошарить". В подавляющем большинстве случаев вы ограничитесь возможностями самого gradle и groovy/kts. И про "оформить в виде плагина", вы будете думать только если "этот вот кусок" у вас кочует из проекта в проект. А в maven - плагин это единственная возможность вообще хоть что-то сделать. Когда вам говорят: "я знаю maven" - это, с большой долей вероятности, означает "я знаю как настраивать вот этот набор плагинов". По себе сужу :-) Чуть-чуть его "внутренней кухни" - не в счет.
Личный опыт - получая maven-проект от незнакомой тебе команды, с вероятностью стремящейся к единице, ты его у себя с первого раза не соберешь :-)
Это не говоря о том, что очень тормознуто работает подсветка синтаксиса и выпадающие подсказки по коду, особенно если писать билд файл на котлине.
Ну в vscode - оно работает "быстро и не правильно", в idea - "медленно, но верно". Это все последствия "компиляции в уме"... у нас же скрипт. Но - честно говоря - пока не придумают как более менее "корректно" фильтровать ф-ции расширения (по контексту, а не по "типу") - это все такое... простыня "на три экрана" - что быстро, что медленно - очень не сильно помогает :-(
P.S. Перечитал очередную "простыню"... чего сказать-то хотел... "гигиена" нужна, что при работе с maven, что при работе с gradle. Совсем без "гигиены" - "... получается само" (с). В maven "гигиену" обеспечивать сильно проще - просто в силу того, что - по сути - вы работаете с xml, а их проверять/выверять по всякому мы умеем. "Гигиена" в gradle требует другого. Собственно, я поэтому и утверждаю, что "ниша" maven - это где сильно важно что "пусть и безобразно, зато единообразно", т.е. за "единообразно" в maven следить сильно проще. Но это именно что "ниша". "100500" разного уровня команд, которые делают "одно большое дело" - тут его "страдают все" хоть как-то, но можно оправдать. Во всех остальных случаях - это лично мой опыт - нет у него никаких преимуществ.
Если не случится какой-нибудь "волшебный пендель" - имхо, все будет как в свое время с cvs/svn vs git. Как мы его не хаяли, он - "медленно но верно" стал general-purpose vcs :-) Теперь все "страдаем" :-)
Maven - надо отдать должное - последние год/два хоть как-то начал шевелится. Вот даже "четверка" уже в третью альфу вышла. Даже обещают таки настраиваемый resolver. Но... "будем делать посмотреть" (с)
В 2023 году стоит учить Gradle сразу на Kotlin DSL.
Groovy больше не нужен.
Мне Gradle не понравился когда попробовал скачать примеры Spring потрошителя, потом попробовал примеры попроще, они должны как говорят работать "из коробки", только в 100% случаев не работали. Примеры с Maven скаченные целиком работали чаще, да и вообще не смотря на многословность он как то проще. Хотя с зависимостями в ЦЕЛОМ в JAVA не очень хорошо, одни зависимости перекрывают другие, зависимости несовместимы друг с другом. Простые сущности типа Template или Table встречаются в 5 - 10 разных экзеплярах разных реализаций разных библиотек. Это очень сильно отличается от того же C# когда изучал ничего такого не было. Вот некоторая разрозненность наверное ещё сильнее раздражает чем даже многословность java. Ну и безальтернативность английской версии IDEA, которая хоть и ушла из России, но найти бесконечную версию Ultimate не состовляет труда. Другой момент что невозможно сказать, что даже после года использования я знаю эту среду. В целом у меня такое отношение, если я работаю на полностью зарубежного заказчика, разговариваю на английском, живу в английской среде я готов полностью к англоязычной IDEA, но для русских разработчиков за 10-15 лет могли бы сделать skin для русско-язычных разработчиков, к примеру существуют японские и корейские скины.
Не бойтесь использовать Gradle