аа

и как у kotlin native дела?

Пока никак

Ток на старте

грейдл огонь, лучшая системаа сборки, с которой я работал. Но там нету интерактивнгой консоли, как в сбт. А это киллер фича

мне мавена за глаза хватает, чтобы собрать на выходе пакет)

Но там походу очень мозгов много

в мавене богомерзкий xml

Да норм xml

ну groovy dsl на много приятнее выглядит

им же надо сделать ту же тонну работы но у скалы плюс, что много чего на "чистой" скале, и может сразу работать а у котлина-то и стдлибы своей нет

плюс всякие пакеты для сборки фронта - bower тот же, который в gradle выглядит лучше, чем в виде json

им же надо сделать ту же тонну работы но у скалы плюс, что много чего на "чистой" скале, и может сразу работать а у котлина-то и стдлибы своей нет

Им надо сделать меньше

Мы к примеру желаем сделать java.lang

А они нет

тогда на кой хер оно будет надо?

а зачем на xml смотреть? мне там только список библиотек указать с версиями - более чем достаточно) этот пом.хмл за историю проекта редактируется несколько раз от силы)

без java.lang?

тогда на кой хер оно будет надо?

Ембедеб

Ну и они типа все сами делать будут

ну не сказал бы. при активной разработке - периодически что-то добавляется. плюс новичку удобнее смотреть - какие либы подключены

а если сборка какая-нибудь хитрая, то вообще смотреть на пом нету силы

Ембедеб

странно как-то с одной стороны, переиспользование джавовских коллекций а с другой — отказ от джавы вообще

гредлл рвёт все сборочные тулзовины по всем параметрам, единственная причина по которой можно использовать сбт - это плей с хотрелоадом во всех остальных случаях даже вопрос не должен возникакть какую систему сборки использовать

странно как-то с одной стороны, переиспользование джавовских коллекций а с другой — отказ от джавы вообще

Я думаю они ещё думают

гредлл рвёт все сборочные тулзовины по всем параметрам, единственная причина по которой можно использовать сбт - это плей с хотрелоадом во всех остальных случаях даже вопрос не должен возникакть какую систему сборки использовать

Нихуя он не рвет

чем гредл лучше мавена?

Главный критерий чтоб собиралось

Всё они собирают

если надо сделать что-то кроме сборки

вот именно

а зачем что-то делать кроме сборки?

вернее не просто депенденси собрать

если надо сделать что-то кроме сборки

То все сборки могут

не так выразился

тулза для сборки и должна именно собирать

я вот деплой на мавене никогда делать не буду - это трешак начинается

Если ты хочешь, чтоб сбт тебе подрочил после сборки, то хз

каждый инструмент должен выполнять свою задачу

сборка, подтягивание зависимостей, разруливание конфликтов последних

чем гредл лучше мавена?

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

и в рамках того, чтоб собрать и запустить тесты - мавен справляется на ура, ничем не хуже остальных вариантов

было пару раз, когда надо было для разных случаем собирать проект по разному. грубо говоря где-то какие-то либы надо было в jar заворачивать, а где-то надо было рядом складывать. на мавене это был адский ад и xml и плагинов

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

Просто они хипстеры?

ну я тогда и перешел на гредл вместе с ними попробовал это сырое нечто и ушел назад на мавен где вот уже несколько лет все ок

на грэдле бы - всего лишь немного кода на понятном языке программирования

Просто они хипстеры?

норм аргумент

год назад я пытался перейти на гредл но застрял на подключении плагина для компиляции аспектов

и вернулся снова на мавен

где все просто работает

и прибито гвоздями и это круто

Я уже говорил, каждый дрочит так, как хочет. Хотите груви или котлин, то берите гредл

ну я тогда и перешел на гредл вместе с ними попробовал это сырое нечто и ушел назад на мавен где вот уже несколько лет все ок

ну и зря, я уже в 3-х конторах гредл внедрил - проще, мощнее, больше гибкости, интуитивнее итд итд

было пару раз, когда надо было для разных случаем собирать проект по разному. грубо говоря где-то какие-то либы надо было в jar заворачивать, а где-то надо было рядом складывать. на мавене это был адский ад и xml и плагинов

а не проще было сделать два разных pom.xml без всяких плагинов?

У меня есть все системы сборок в проектах и это один хер, даже кстати ант есть)

мне нравится мавен и устраивает сбт но гредл я так и не смогу постичь(его преимущества)

там не в помах дело. там именно нужно было собрать проект не так как мавен привык

на грэдле бы - всего лишь немного кода на понятном языке программирования

Таки спорный вопрос

ну почему спорный?

Потому что бывают адские скрипты на груви для гредла

Не для всего есть плагины)

бывают, в мавене это адские скрипты на ант плагине

На мавене как раз плагин скорее всего уже есть)))

мавен был норм в свое время

А мю и ливерпуль сегодня играют?

но там любое нестандартное действие или заставляет писать плагин, или писать тонны адского xml

мне как-то надо было просто файлик скопировать после какого-то шага. Вылилось в примерно 15 строк xml писанины. В грейдле это была одна строка

мне как-то надо было просто файлик скопировать после какого-то шага. Вылилось в примерно 15 строк xml писанины. В грейдле это была одна строка

Antrun ?

ERROR: S client not available

Вы как Барух, ей богу?

если уж совсем прям нужно что-то там копировать или хитрое делать после разных шагов - никто не мешает написать скрипт на той же скале - где вызвать сборку по шагам и вставить между ними что угодно

если уж совсем прям нужно что-то там копировать или хитрое делать после разных шагов - никто не мешает написать скрипт на той же скале - где вызвать сборку по шагам и вставить между ними что угодно

...дописать "немного" дсля, и назвать это sbt

yabt уж тогда

если уж совсем прям нужно что-то там копировать или хитрое делать после разных шагов - никто не мешает написать скрипт на той же скале - где вызвать сборку по шагам и вставить между ними что угодно

и это будет франкенштейн, а в гредле это предусмотрено дизайном системы

Идите соберите гредлом scala-native ?

есть под рукой пример гредл билда с такими вставками?

plugins { id "edu.sc.seis.macAppBundle" version "2.1.0" } macAppBundle { mainClassName = "com.agd.report.tool.Main" bundleJRE = false javaProperties.put("apple.laf.useScreenMenuBar", "true") } group 'com.agd' version '1.0-SNAPSHOT' apply plugin: 'java' sourceCompatibility = 1.8 repositories { mavenCentral() } //create a single Jar with all dependencies task fatJar(type: Jar) { manifest { attributes 'Implementation-Title': 'Gradle Jar File Example', 'Implementation-Version': version, 'Main-Class': 'com.agd.report.tool.Main' } baseName = project.name + '-all' from { configurations.compile.collect { it.isDirectory() ? it : zipTree(it) } } with jar } dependencies { compile "commons-io:commons-io:2.4" compile "javax.mail:mail:1.4" compile 'org.apache.commons:commons-csv:1.1' compile 'org.slf4j:slf4j-api:1.7.12' compile 'ch.qos.logback:logback-classic:1.1.3' }

в мавене конечно есть плагин для этого

но согласитесь - выглядит все равно элегантно

а какая часть тут про "после конкретного шага сделать что-то необычное для просто сборки" ?

ну таск который собирает в огромную джарку со всеми либами, чего мавен по дефолту не делает

На прошлой работе система требует: 1. выкачать неведомую херню под названием платформа в виде зип файла, распаковать её, подключить все зависимости в проект. 2. сделать километр настроек для того чтобы взлетел проект на эклипс, очень специфичная херня с osgi 3. стопицот шагов по собиранию exe-шника под винду с использованием винамповских сборщиков. 4. какая-то лютая кастомизация под разные платформ (но это уже после меня) никакая другая сборка просто такого даже рядом не осилит либо сложность будет запредельная. Гредлом всё сделали легко, плюс ещё был переходный период в пол года с анта на гредл и там приходилось интегрироваться с имеющейся кучей кода

fat jar - уже давно является частью стандартных вариантов билда и для него действительно давным давно есть плагин - так что плохой приме наверное с фатжаром)

на уровне плагинов да

На прошлой работе система требует: 1. выкачать неведомую херню под названием платформа в виде зип файла, распаковать её, подключить все зависимости в проект. 2. сделать километр настроек для того чтобы взлетел проект на эклипс, очень специфичная херня с osgi 3. стопицот шагов по собиранию exe-шника под винду с использованием винамповских сборщиков. 4. какая-то лютая кастомизация под разные платформ (но это уже после меня) никакая другая сборка просто такого даже рядом не осилит либо сложность будет запредельная. Гредлом всё сделали легко, плюс ещё был переходный период в пол года с анта на гредл и там приходилось интегрироваться с имеющейся кучей кода

все это к сборке библиотек не имеет отношения.

в грэдле можно сделать тоже самое без плагинов и не так-то и сложно

я соглашусь только, что в 90% случаев разницы между мавеном и грэдлом не видно

грэдл просто поприятнее. но в то же время gradle объединяет преимущества мавена и анта в обертке нормального dsl и скриптового языка программирования

зачем писать что то самому если есть готовый вариант который использует куча других людей?

для мавена на все есть плагины

можно заключить, что в рамках зачаи сборки библиотеки - гредл не дает абсолютно никаких преимуществ? Просто позволяет делать какие-то другие вещи не связанные с основной задаче - не так костыльно? ))

не на все

пример плохой, но показательный. просто как пример

для мавена на все есть плагины

далеко не на все)

можно написать свой если нужно

> Mikhail можно заключить, что в рамках зачаи сборки библиотеки - гредл не дает абсолютно никаких преимуществ? ну подключать dependency они оба одинаково умеют

то, что описал вячеслав - я бы действительно не стал делать на мавене и ипался бы со своим плагином. нужно быть слегка знатоком мавена для этого - что мне малоинтересно

*не ипался бы

там не сложнее чем DSL Gradle

я бы больше сказал написать плагин для мавена на много легче чем разобраться в DSL гредла

намного*