Всем привет, подскажите пожалуйста, стоит ли переезжать с мавена на gradle? прочитал в интернете по этой теме, многие советуют все же переехать, но с мавеном как по мне проще решать всякого рода вопросы, как-то он вроде понятней что ли… Кто переезжал, может подсказать плюсы или минусы?
Спасибо…
Все зависит от вашего кейса.
В целом можно посмотреть на любое сравнение, например Gradle or Maven - A Dilemma и сделать для себя выводы.
Если грубо, то если вам maven нужен просто для управления зависимостями, то особого смысла менять на gradle нет.
Как-то так я и думал, спасиб… Каких-то сверх важных вещей там не заметил…
Для автоматизации абсолютно не важно чем пользоваться
Собственно переезжать ради переезда не стоит =)
Я только на одном проекте отказался от мавена в пользу градла, т.к. функциональности мавена не хватило (либо я плохо курил документацию)
Да я так посмотрел, вроде и в правду смысла большого нет, хотя градл довольно функциональней. Но походу будет смысл переезжать только если тесты лягут рядом с проектом, в котором градл… Всем спасибо 
@dimand58, а чего не хватало?
@evgmoskalenko нужно было целую папку с jar’никами добавить в classpath (или как dependencies). В мавене я либо перезатирал classpath (и сам мавен ломался), либо каждый jar’ник добавлял как зависимость.
В gradle же просто сделал так:
testomat.io управление авто тестами
compile fileTree(dir: '.\\libs', include: ['*.jar'])И в корне проекта, в папке libs, разместил все те jar, что хотел добавить в classpath
Конечно, зависит от проекта, но вообще-то Gradle на порядок мощнее.
И быстрее, и красивее. И не качает весь интернет.
Простой пример. Когда нужно запустить тесты и firefox и chrome, в Gradle для этого нужно сделать всего-навсего два таска:
task tests-chrome(type: Test) {
systemProperties['selenide.browser'] = 'chrome'
}
task tests-firefox(type: Test) {
systemProperties['selenide.browser'] = 'firefox'
}
И запускать их простой командой:
gradle tests-chrome
gradle tests-firefox
А в Maven для этого придётся написать кучу XML с разными профилями. Запускать которые придётся через ж… (типа mnv test -Pfirefox).
Сидит программист глубоко в отладке.
Подходит сынишка:
— Папа, почему солнышко каждый день встает на востоке, а садится на западе?
— Ты это проверял?
— Проверял.
— Хорошо проверял?
— Хорошо.
— Работает?
— Работает.
— Каждый день работает?
— Да, каждый день.
— Тогда ради бога, сынок, ничего не трогай, ничего не меняй!!!
Работает - не трожь, не мой подход Рано или поздно с новой фичей - отвалится…
Ну тут не тот случай. Ты же не будешь допиливать кхм maven или что-то вокруг него. Я думаю никакого профита это не принесет, только если это действительно не будет удобнее для тебя и твоих коллег.
За N лет работы с maven ни разу не встречал чего-либо, чего бы мне не хватало для решения automation задач. Более того, с годами у вас наверняка останутся какие-то шаблоны, которые вы будете переиспользовать на новых проектах. Создаете архетип с минимально необходимой конфигурацией, и вперед. При этом, никаких проблем и потребностей перехода на gradle не возникнет.
Чисто любопытства ради, при наличии времени и желания, на стартующем с нуля проекте, можно было бы поиграться с gradle. А так, весьма сомнительная затея.
Ну, это то же самое, что бухгалтеры в своё время считали, что компьютеры им не нужны. А ковбоям не нужны были автомобили. А крестьянам картошка.
Я знаю людей, которые до сих пор используют ant и уверены, что ни maven, ни gradle им нафиг не сдался.
Я тоже могу привести аналогию. Что же Selenide до сих пор на Java 7 завис? Хотя 8-ке то 2+ года, а в сентябре будет первый релиз 9ки… Дальше развивать мысль стоит? Или в ход пойдут популярные рассказы о пожизненном саппорте legacy динозавров / строгих company policy / широком комьюнити сторонников старины?
У каждого своя история. Вы не видите весомых причин переходить на 8-ку, другие - на gradle. 
Вот собственно и все.
Так это совсем другая история. Selenide - это библиотека, которую используют другие люди. Я просто опасаюсь, что многие из них сидят на семёрке, и поэтому переходить на восьмёрку нельзя. Только поэтому.
Open-source на то и open-source, что автор волен делать то, что пожелает, без каких-либо обязательств. Несомненно, есть определенные морально-этические нормы, годами накопленный уровень уважения, лайков, звезд и т.п. Но трястись из-за того “вечного” сегмента legacy проектов, которые до сих пор сидят на <=7 java - полный нонсенс. Всегда найдутся недовольные, этого не избежать. Но жизнь идет, технологии развиваются, и на тот процент “отпавших” из-за перевода на новую версию java найдется такой же или еще больший процент “прибывших”. Так что никакая это не другая история. С таким подходом можно вечно сидеть на 7й java. А потом через пару лет автор какой-нибудь новой модной библиотеки будет смеяться и проводить аналогии с условным selenide, так же, как вы делаете с ant, maven и gradle, либо бухгалтерами и ковбоями.
Мысль интересная, но не улавливаю логики. Откуда вдруг возьмётся процент прибывших? Никто не начнёт использовать Selenide только потому, что она компилируется только с Java 8. Тут никакой связи. Что бы они ни использовали - Java 7 или Java 8 - им лучше всего подойдёт библиотека, которая поддерживает и то, и другое.
А Selenide не переходит на Java 8 не потому, что я трясусь, а потому, что нет необходимости. Я активно использую Java 8 в работе и знаю её возможности. И ни одна из них пока не нужна в Selenide. Поэтому просто нет смысла.
А почему же вы тогда так уверены в том, что у пользователей maven должна вдруг появиться резкая необходимость перехода на gradle? Я пока не увидел ни одного весомого аргумента в пользу gradle в контексте автоматизации.
А я этого и не говорил.
Я говорю о том, что есть огромная разница между “я хорошо знаю, что там, и мне это не нужно” и “точно не знаю, что там, но мне это не нужно, мне и так хорошо”.
P.S. преимущества у градла всё-таки есть и в контексте автоматизации тестирования - я их в первом комментарии описал.
А можно эти пункты как-то поподробнее обосновать? Не пробовал Gradle, пока только с Maven’ом “развлекаюсь” и не совсем понимаю, чем он может быть нам лучше в рамках нашего тестирования.
Интересно понять, стоит ли его пробовать в будущих проектах вместо maven’а или пока и так сойдет и лучше не тратить время на это и заниматься самим тестированием.