Comments 48
То есть внутри определения задачи может находиться произвольный код на Groovy. И сами задачи — полноценный объект Groovy. А это значит, что у них есть свойства и методы, которые позволяют ими управлять. Например, добавляя новые действия.
Супер!
Автору спасибо.
Я считаю, что за подобным подходом есть будущее сборок. XML описание сборки, которая чуточку нетревиальнее чем есть в документации — это какой то кошмар. Говорю имея за плечами громадный опыт msbuild и nant
Мне кажется наличие таких мощных инструментов для многих сыграет важную роль в определении конечного jvm based функционального языка. Получается что сейчас groovy начинает потихоньку перевешивать scala. Посмотрим как дальше пойдет.
амм… начинает? потихоньку? я скажу только одно слово: «Grails»… так уж вышло, что в наше время успех ЯП определяется во многом наличием крутого веб-фрэймворка… И что-то я давненько не встречал упоминаний Lift вообще-то…
вы это о чем?
об «определении конечного jvm based функционального языка», не? в том смысле, что groovy/grails как-то уделывает scala/lift… -> приток новичков в комьюнити groovy -> дополнительный стимул для развития языка… далее по кругу. это на самом деле был оффтопик… вообще-то.
а откуда дровишки? почем значете что уделывает?
отец, слышишь, рубит, а Я отвожу… отец рубит, понимаете? на самом деле, исключительно субъективно. в смысле упоминаний больше попадается на глаза. шум, короче говоря. no offence… я сам как-бы нуб в java мире, и мне не хочется делать ставку на язык, который в перспективе зачахнет, или станет уделом небольшой группы снобов… опять же, если я не в теме, или не там смотрю, или утрирую, например и развожу панику, ткните и объясните. полезно будет. и не только мне, я думаю.
ээ… начинает потихоньку? groovy уже давно стал де-факто «внутренним скриптовым языком» во многих java-проектах — да хоть с том же андроиде.
Groovy совсем не конкурент Scala. А вот их комбинация как скриптового и основного языка — это уже интересно.
еще еще еще…
Концепция хорошая. Непонятно только, почему язык — не Java. Забабахать хорошую модель классов, читабельность будет не сильно хуже.
Если речь идет о скриптах, то уже давно есть интерпретатор Java — BeanShell
Если речь идет о скриптах, то уже давно есть интерпретатор Java — BeanShell
на groovy можно писать синтасисом java'ы, но зачем?
Одна из ключевых особенностей Gradle — предоставление пользователю большой свободы в расширении Convention-over-Configuration. Возможности по расширению у языков со статической типизацией априори на много меньше, чем у языков с динамической типизацией.
Т.е., Gradle на Java выглядел бы очень и очень многословно. А раз многословно, то появляются проблемы с решением задач и дальнейшим их сопровождением.
Т.е., Gradle на Java выглядел бы очень и очень многословно. А раз многословно, то появляются проблемы с решением задач и дальнейшим их сопровождением.
gradle клёвый, да.
жаль пока интеграции с IDEA/TeamCity нет и с андроидом я его не смог подружить :(
жаль пока интеграции с IDEA/TeamCity нет и с андроидом я его не смог подружить :(
Интеграция с IDEA висит в YouTrack и за нее активно голосуют, присоединяйтесь.
Что касается поддержки в Teamcity, то она появилась в последнем EAP — см. release notes. Думаю, к выпуску 6.0 Gradle будет поддерживаться вполне прилично.
Что касается поддержки в Teamcity, то она появилась в последнем EAP — см. release notes. Думаю, к выпуску 6.0 Gradle будет поддерживаться вполне прилично.
Обратите внимание на то, что многие задачи были отмечены UP-TO-DATE.
Главное что бы это все нормально работало, а не как в Maven, на разросшемся проекте после внесения правок в исходники maven install собирает какую-то кашу из старых/новых сырцов, приходится делать maven clean install. Но это так оффтоп.
На самом деле хотелось бы понять насколько сложен переход с maven, и даст ли он какие-то плоды. Например maven иногда глючит с депсами, в офлайне вешает всю систему сборки эклипса на глухо, ломает периодически debug (эклипс не может найти сырцы проектов). И это только мои личные проблемы с maven на самом деле их больше.
И тем не менее я не ощущаю в чем профит от Gradle, я конечно признаю гибкое конфигурирование проекта это круто, но где это применять людям которые не разрабатывают hibernate-core?
Как в грейдле реализовано разрешение конфликтов? Если один проект тянет хибернейт 3.1 а другой 3.5 а третий 2.0, что будет? Где спецификация?
Понимаете совсем не хочется менять шило на мыло.
Еще есть такая порочная настройка в Eclipse: Maven -> Resolve workspace dependencies. Для Gradle есть похожий аналог, или нужно будет депы инсталить в репозитарий после каждого изменения исходного кода?
Ни в коем случае не призываю бросить все и мигрировать на Gradle. Это слишком.
Инкрементальная сборка действительно нормально работает. Каши из старых и новых сырцов пока не встречалась.
Переход с maven2 возможен. Вплоть до скриптов автоматического преобразования. Решит ли это все ваши проблемы? Сомневаюсь. Но точно даст возможность попытаться их решить своими собственными руками, а не рытьем документации maven2
Про разрешение конфликтов в зависимостях. Управление зависимостями в Gradle осуществляется средствами Apache Ivy — вот спецификации. Что касательно преимуществ перед Maven2 — то вот небольшое сравнение.
Решать вам.
Инкрементальная сборка действительно нормально работает. Каши из старых и новых сырцов пока не встречалась.
Переход с maven2 возможен. Вплоть до скриптов автоматического преобразования. Решит ли это все ваши проблемы? Сомневаюсь. Но точно даст возможность попытаться их решить своими собственными руками, а не рытьем документации maven2
Про разрешение конфликтов в зависимостях. Управление зависимостями в Gradle осуществляется средствами Apache Ivy — вот спецификации. Что касательно преимуществ перед Maven2 — то вот небольшое сравнение.
Решать вам.
Про Gradle и Maven2: habrahabr.ru/blogs/java/106717/
К Maven 3 тоже добавили поддержку JVM языков: polyglot.sonatype.org/index.html
Хочу сделать запускаемый jar-файл, требуемые бибилиотеки к которому прописаны в манифесте через classpath. Как-то так:
Class-Path: libs/xxx.jar…
Как это правильно сделать?
Class-Path: libs/xxx.jar…
Как это правильно сделать?
Если грубо, то достаточно воспользоваться примером из статьи и заменить
На набор нужных вам атрибутов
attributes demo: 'habr.ru'
На набор нужных вам атрибутов
Если не лень провести 2-3 эксперимента, то можно попробовать сформировать значние атрибута class-path на основе зависимостей в sourceSet.main
Решение нашел, забыл написать об этом.
Думаю, что пригодится кому-либо:
gradle.taskGraph.whenReady { taskGraph ->
def classpath = sourceSets.main.compileClasspath.collect{
jarDependenciesLib + File.separator + it.name
}.join(', ')
jar.manifest.attributes 'Main-Class': mainclass, 'Class-Path': classpath
}
Думаю, что пригодится кому-либо:
gradle.taskGraph.whenReady { taskGraph ->
def classpath = sourceSets.main.compileClasspath.collect{
jarDependenciesLib + File.separator + it.name
}.join(', ')
jar.manifest.attributes 'Main-Class': mainclass, 'Class-Path': classpath
}
началось… всё, хана концепту…
Чего вы от меня ожидали? С Groovy почти не знаком, не говоря уже о Gradle.
Дорогу осилит идущий… это я к тому, что со временем получится и более грамотный скрипт.
Дорогу осилит идущий… это я к тому, что со временем получится и более грамотный скрипт.
Ну уж, «хана». Человек попробовал. И получил требуемый результат.
Возможно, это стоило бы сделать подругому. Я бы, к примеру, перенёс этот код внутрь task'a «jar». А вы?
Возможно, это стоило бы сделать подругому. Я бы, к примеру, перенёс этот код внутрь task'a «jar». А вы?
Я не об этом. Пример чётко показывает, что люди начинают сразу же колошматить свои «анто-велосипеды». Главная мысль мавена ведь: 1 проект -> 1 артифакт + дока + тесты + конфиг, то есть — берёшь человека на работу, а ему знакома уже эта конструкция. Что мы видем из выше изложенного: берём человека на работу и начинается почему-так-и-почему-не-этак-и-как-это-работает-вообще (не Gradle, а build проекта).
пс: 2 раза толстой книгой по рукам! +))
пс: 2 раза толстой книгой по рукам! +))
Блин, какой кошмар! Полная свобода действий — это конечно же круто, но где в проекте вы видели только спецов? Это ведь будет выглядеть так же, как «чёрт-его-знает-какие-ант-скрипты-в-которых-уже-не-понять-что-к-чему». То есть, на эту штуку нужно сажать архитектора и билд-менеджера, а другим просто лупить толстой книгой по рукам!
В принципе да, так и есть. Частично от этого предохраняет активное использование Convention-over-Configuration. Частично — дисциплина :)
На maven тоже можно такого наворотить — сам черт не разберёт :)
На maven тоже можно такого наворотить — сам черт не разберёт :)
Думаю, что зря драматизируете.
Чем подход к написанию билд-скриптов отличается от обычного программирования? Никто не отменял простейших принципов разумности, понятности, простоты кода.
Из всего можно сделать говно.
Чем подход к написанию билд-скриптов отличается от обычного программирования? Никто не отменял простейших принципов разумности, понятности, простоты кода.
Из всего можно сделать говно.
Sign up to leave a comment.
Gradle: Tasks Are Code