Комментарии 17
Позвольте заметить, у вас в заголовке опечатка, там лишняя буква "Л" перед словом ад.
и косячить еще быстрее!
Если вы надумали удалить /etc из вашего gradle скрипта и по стечению обстоятельств у этого скрипта есть права для этого, то это откровенный поиск приключений на пятую точку опоры. Но даже этого можно избежать, следуя принципу доверяй да проверяй, на стороне CI, например не пропускать все что не является управлением зависимостями. Это кстати гораздо проще достигается в sbt
но замахнуться на священный maven, пока, не решился никто.
Не совсем понятно что тут имелось ввиду, maven просто погружается в забвение, где ему и самое место.
Подход, когда все разделено и физически невозможно смешать, мне гораздо ближе: релиз разбивается на конечное число атомарных шагов, простых и понятных. Но, пока мы не там.
это со стороны моего опыта
К сожалению, это только со стороны вашего опыта. Например мы каких-то тормозов в работе gradle не наблюдали (т.е. компиляторы тратят время, upload тратит время, однако самого gradle при этом почти не видно). Здесь можно даже увидеть, что современный gradle может обгонять современный maven. Так что it depends.
тянут неимоверное количество плагинов
У нас их порядка пяти. Из них kotlin/spring boot, которые так и так много где будут.
отчего упала непонятно
https://docs.gradle.org/current/userguide/logging.html ?
не пойми сколько
IntelljJ Idea показывает, сколько времени работали таски. И плюс здесь есть рекомендации, если какие-то задачи работают медленно.
Инструмент, он невиноват, когда его неправильно используют. 100% тормозов в мавене, да и грейдле, были вызваны кривыми руками. И там и там можно такого натворить, что е-ге-гей!
Apache Hadoop — 144 участника на github, Hive — 168. Spark — 1285, Hbase — 196. Это только четыре компонента из большой экосистемы Hadoop. Народу работает более чем много для типичного проекта (хотя только spark сопоставим скажем со spring по числу людей). Все собираются maven. Даже написанный на скале Spark.
Так где можно глянуть на пару ваших проектов размером с Apache Hadoop?
Бизнес модель Spark ничем не отличается от любого ос проекта, написан он может быть на чем угодно, а работает из java и scala, к сожалению кто говорит java подразумевает maven на уровне предприятия.
Народу работает более чем много для типичного проекта (хотя только spark сопоставим скажем со spring по числу людей).
Количество не означает качесто.
Так где можно глянуть на пару ваших проектов размером с Apache Hadoop?
Все проекты в мире под андроид собираются из gradle и что, о чем это говорит? Да ни очем, из раздела да мой папа знает каратэ, а мой айкидо, итд...
Не испытываю никакого сожаления. И еще человек 30 разработчиков вокруг. Что мы все делаем не так?
>Количество не означает качество.
Количество участников означает сложность проекта. Практически однозначно. Применительно к перечисленным проектам я могу спокойно утверждать, что Spark прилично сложнее, чем Spring Framework, потому что достаточно хорошо знаю оба. А хадуп скорее всего на порядок сложнее.
А уж коли вы собрались выступить за качество — так вы должны показать, что скажем Spark чем-то хуже Spring. А пока вы это не показали — какой может быть разговор про качество?
>Все проекты в мире под андроид собираются из gradle и что, о чем это говорит?
Это говорит очень о многом. В первую очередь — об их масштабе.
Упростим задачу. Покажите мне хотя бы один проект под андроид, в котором 1285 человек участников? Я вот априори более чем уверен, что такого не существует.
Кстати, если бы вы сразу сказали, что в мире мобильных приложений мавен (и далее по тексту) — я бы наверное и спорить не стал. Мне не нравятся только обобщения вида «все проекты в мире», по одной простой причине: я вот лет 10 минимум уже работаю на разные крупные банки, и совершено точно знаю, что работая внутри, никогда не видел и не слышал о большей части проектов, которые там делаются. В лучшем случае — процентов 10 может быть видел. То есть, я бы даже про свою компанию начиная с определенного ее размера так бы не стал обобщать. А уж за весь мир — и подавно.
Что мы все делаем не так?
Откуда мне знать, я не врач и не психолог
Применительно к перечисленным проектам я могу спокойно утверждать, что Spark прилично сложнее, чем Spring Framework, потому что достаточно хорошо знаю оба.
Причем здесь мейвен? Вам же сказали что его выбрали лишь бы угодить интерпрайзу.
А уж коли вы собрались выступить за качество — так вы должны показать, что скажем Spark чем-то хуже Spring.
Нет тут речь идет о древне русской мудрости, которая гласит что количество не означает качество, только и всего.
Это говорит очень о многом. В первую очередь — об их масштабе.
Нет это говорит лишь о том что в какой то момент выбор пал на более современную технологию, от которой конечный пользователь в восторге, только и всего.
Покажите мне хотя бы один проект под андроид, в котором 1285 человек участников? Я вот априори более чем уверен, что такого не существует.
Ну кто его знает что там в закромах проприетарных проектов творится, опять же см про качесто и кол-во.
я вот лет 10 минимум уже работаю на разные крупные банки
Искрене собалезную, я как-то в прошлом работал на JPMC, меня хватило на 2 мес их дурдома, больше с банками дела не имею.
На данный момент с ним у меня было меньше всего проблем. Хотя это скорее всего объясняется тем что с ним у меня больше всего опыта.
Но что я слышал от других:
— ненависть к XML перекидывается на инструменты, что его используют, те не любят за конфигурацию через xml
— сложность в изменении стандартного воркфлоу, по сути только через кастомные плагины
— легко получить «депенденси хелл», когда изменение версии одной из библиотек непредсказуемо ломает билд
— конфигурация быстро разрастается и становится сложной к управлению и пониманию
Как еще один вариант: собирать snapshot и ставить версию = хешу, в случае когда тег не определен.
В таком варианте есть свои плюсы и минусы: к плюсом можно отнести однозначное понимание что попало в сборку, разночтений быть не может; к минусам, неочевидно куда мы движемся меняя одну страшную строчку на другую, семантическая версионность говорит нам идем ли мы вперед (версия стала больше) или назад (меньше).
Ну вот например, axelfontaine.com/blog/final-nail.html
Первый пост из этой серии был написан еще в 2011 году. А в последнем от 2016 года на первый взгляд описано ровно такое же решение, как и у вас.
Релизим проект на Java с Maven на новый лад