Есть отличная удаленная работа для php+codeception+jenkins+allure+docker спецов. 100% remote! Присоединиться к проекту

Остаться на MAVEN или переехать на Gradle? :-)

gradle
maven
Теги: #<Tag:0x00007f7b658e0660> #<Tag:0x00007f7b658e0458>

(Eugene Moskalenko) #1

Всем привет, подскажите пожалуйста, стоит ли переезжать с мавена на gradle? прочитал в интернете по этой теме, многие советуют все же переехать, но с мавеном как по мне проще решать всякого рода вопросы, как-то он вроде понятней что ли… Кто переезжал, может подсказать плюсы или минусы?

Спасибо…


(Artem Nikitin) #2

Все зависит от вашего кейса.
В целом можно посмотреть на любое сравнение, например http://www.scmtechblog.net/2015/03/gradle-or-maven-dilemma.html и сделать для себя выводы.
Если грубо, то если вам maven нужен просто для управления зависимостями, то особого смысла менять на gradle нет.


(Eugene Moskalenko) #3

Как-то так я и думал, спасиб… Каких-то сверх важных вещей там не заметил…


(Sergey Pirogov) #4

Для автоматизации абсолютно не важно чем пользоваться


(Dmitrii Demin) #5

Собственно переезжать ради переезда не стоит =)
Я только на одном проекте отказался от мавена в пользу градла, т.к. функциональности мавена не хватило (либо я плохо курил документацию)


(Eugene Moskalenko) #6

Да я так посмотрел, вроде и в правду смысла большого нет, хотя градл довольно функциональней. Но походу будет смысл переезжать только если тесты лягут рядом с проектом, в котором градл… Всем спасибо :slight_smile:

@dimand58, а чего не хватало?


(Dmitrii Demin) #7

@evgmoskalenko нужно было целую папку с jar’никами добавить в classpath (или как dependencies). В мавене я либо перезатирал classpath (и сам мавен ломался), либо каждый jar’ник добавлял как зависимость.
В gradle же просто сделал так:

compile fileTree(dir: '.\\libs', include: ['*.jar'])

И в корне проекта, в папке libs, разместил все те jar, что хотел добавить в classpath


(asolntsev) #8

Конечно, зависит от проекта, но вообще-то 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).


(rmerkushin) #9

Сидит программист глубоко в отладке.
Подходит сынишка:
— Папа, почему солнышко каждый день встает на востоке, а садится на западе?
— Ты это проверял?
— Проверял.
— Хорошо проверял?
— Хорошо.
— Работает?
— Работает.
— Каждый день работает?
— Да, каждый день.
— Тогда ради бога, сынок, ничего не трогай, ничего не меняй!!!


(Eugene Moskalenko) #10

Работает - не трожь, не мой подход :slight_smile: Рано или поздно с новой фичей - отвалится…


(rmerkushin) #11

Ну тут не тот случай. Ты же не будешь допиливать кхм maven или что-то вокруг него. Я думаю никакого профита это не принесет, только если это действительно не будет удобнее для тебя и твоих коллег.


(Sergey Korol) #12

За N лет работы с maven ни разу не встречал чего-либо, чего бы мне не хватало для решения automation задач. Более того, с годами у вас наверняка останутся какие-то шаблоны, которые вы будете переиспользовать на новых проектах. Создаете архетип с минимально необходимой конфигурацией, и вперед. При этом, никаких проблем и потребностей перехода на gradle не возникнет.

Чисто любопытства ради, при наличии времени и желания, на стартующем с нуля проекте, можно было бы поиграться с gradle. А так, весьма сомнительная затея.


(asolntsev) #13

Ну, это то же самое, что бухгалтеры в своё время считали, что компьютеры им не нужны. А ковбоям не нужны были автомобили. А крестьянам картошка.

Я знаю людей, которые до сих пор используют ant и уверены, что ни maven, ни gradle им нафиг не сдался.


(Sergey Korol) #14

Я тоже могу привести аналогию. Что же Selenide до сих пор на Java 7 завис? Хотя 8-ке то 2+ года, а в сентябре будет первый релиз 9ки… Дальше развивать мысль стоит? :slight_smile: Или в ход пойдут популярные рассказы о пожизненном саппорте legacy динозавров / строгих company policy / широком комьюнити сторонников старины?

У каждого своя история. Вы не видите весомых причин переходить на 8-ку, другие - на gradle. :wink: Вот собственно и все.


(asolntsev) #15

Так это совсем другая история. Selenide - это библиотека, которую используют другие люди. Я просто опасаюсь, что многие из них сидят на семёрке, и поэтому переходить на восьмёрку нельзя. Только поэтому.


(Sergey Korol) #16

Open-source на то и open-source, что автор волен делать то, что пожелает, без каких-либо обязательств. Несомненно, есть определенные морально-этические нормы, годами накопленный уровень уважения, лайков, звезд и т.п. Но трястись из-за того “вечного” сегмента legacy проектов, которые до сих пор сидят на <=7 java - полный нонсенс. Всегда найдутся недовольные, этого не избежать. Но жизнь идет, технологии развиваются, и на тот процент “отпавших” из-за перевода на новую версию java найдется такой же или еще больший процент “прибывших”. Так что никакая это не другая история. С таким подходом можно вечно сидеть на 7й java. А потом через пару лет автор какой-нибудь новой модной библиотеки будет смеяться и проводить аналогии с условным selenide, так же, как вы делаете с ant, maven и gradle, либо бухгалтерами и ковбоями.


(asolntsev) #17

Мысль интересная, но не улавливаю логики. Откуда вдруг возьмётся процент прибывших? Никто не начнёт использовать Selenide только потому, что она компилируется только с Java 8. Тут никакой связи. Что бы они ни использовали - Java 7 или Java 8 - им лучше всего подойдёт библиотека, которая поддерживает и то, и другое.

А Selenide не переходит на Java 8 не потому, что я трясусь, а потому, что нет необходимости. Я активно использую Java 8 в работе и знаю её возможности. И ни одна из них пока не нужна в Selenide. Поэтому просто нет смысла.


(Sergey Korol) #18

А почему же вы тогда так уверены в том, что у пользователей maven должна вдруг появиться резкая необходимость перехода на gradle? Я пока не увидел ни одного весомого аргумента в пользу gradle в контексте автоматизации.


(asolntsev) #19

А я этого и не говорил. :slight_smile:

Я говорю о том, что есть огромная разница между “я хорошо знаю, что там, и мне это не нужно” и “точно не знаю, что там, но мне это не нужно, мне и так хорошо”.

P.S. преимущества у градла всё-таки есть и в контексте автоматизации тестирования - я их в первом комментарии описал.


(Михаил Братухин) #20

А можно эти пункты как-то поподробнее обосновать? Не пробовал Gradle, пока только с Maven’ом “развлекаюсь” и не совсем понимаю, чем он может быть нам лучше в рамках нашего тестирования.

Интересно понять, стоит ли его пробовать в будущих проектах вместо maven’а или пока и так сойдет и лучше не тратить время на это и заниматься самим тестированием.