Comments 48
То есть внутри определения задачи может находиться произвольный код на Groovy. И сами задачи — полноценный объект Groovy. А это значит, что у них есть свойства и методы, которые позволяют ими управлять. Например, добавляя новые действия.

Супер!

Автору спасибо.
Да, это весьма существенное новшество — полноценный язык для сборки.
Я считаю, что за подобным подходом есть будущее сборок. XML описание сборки, которая чуточку нетревиальнее чем есть в документации — это какой то кошмар. Говорю имея за плечами громадный опыт msbuild и nant
Мне кажется наличие таких мощных инструментов для многих сыграет важную роль в определении конечного jvm based функционального языка. Получается что сейчас groovy начинает потихоньку перевешивать scala. Посмотрим как дальше пойдет.
амм… начинает? потихоньку? я скажу только одно слово: «Grails»… так уж вышло, что в наше время успех ЯП определяется во многом наличием крутого веб-фрэймворка… И что-то я давненько не встречал упоминаний Lift вообще-то…
об «определении конечного jvm based функционального языка», не? в том смысле, что groovy/grails как-то уделывает scala/lift… -> приток новичков в комьюнити groovy -> дополнительный стимул для развития языка… далее по кругу. это на самом деле был оффтопик… вообще-то.
отец, слышишь, рубит, а Я отвожу… отец рубит, понимаете? на самом деле, исключительно субъективно. в смысле упоминаний больше попадается на глаза. шум, короче говоря. no offence… я сам как-бы нуб в java мире, и мне не хочется делать ставку на язык, который в перспективе зачахнет, или станет уделом небольшой группы снобов… опять же, если я не в теме, или не там смотрю, или утрирую, например и развожу панику, ткните и объясните. полезно будет. и не только мне, я думаю.
и ps ещё: я даже про clojure и то больше вижу упоминаний в последнее время, чем про scala…
ээ… начинает потихоньку? groovy уже давно стал де-факто «внутренним скриптовым языком» во многих java-проектах — да хоть с том же андроиде.
ну или скажем first-class bundled поддержка groovy в IDEA (даже опенсорсной CE) и NetBeans
UFO landed and left these words here
под андроидом я хотел сказать Android SDK, для layoutopt он используется
Groovy совсем не конкурент Scala. А вот их комбинация как скриптового и основного языка — это уже интересно.
Частично согласен, но это пока не очень популярная ветка и так не очень популярного языка. ;)
Scala — это естественный заменитель Java + мощный язык для написания действительно сложных вещей.

Groovy же очень хорош для разных скриптов (в т.ч. встраиваемых) и темплейтов. Много удобных расширений по сравнению с JDK для работы с файлами, строками, XML.
Концепция хорошая. Непонятно только, почему язык — не Java. Забабахать хорошую модель классов, читабельность будет не сильно хуже.

Если речь идет о скриптах, то уже давно есть интерпретатор Java — BeanShell
Одна из ключевых особенностей Gradle — предоставление пользователю большой свободы в расширении Convention-over-Configuration. Возможности по расширению у языков со статической типизацией априори на много меньше, чем у языков с динамической типизацией.

Т.е., Gradle на Java выглядел бы очень и очень многословно. А раз многословно, то появляются проблемы с решением задач и дальнейшим их сопровождением.
gradle клёвый, да.
жаль пока интеграции с IDEA/TeamCity нет и с андроидом я его не смог подружить :(
Интеграция с IDEA висит в YouTrack и за нее активно голосуют, присоединяйтесь.

Что касается поддержки в Teamcity, то она появилась в последнем EAP — см. release notes. Думаю, к выпуску 6.0 Gradle будет поддерживаться вполне прилично.
и про голосование, и про EAP я, конечно же, знаю, но в 10ке этого не будет точно, да и когда ещё мы на 6.0 перейдём…
на самом деле пока что меня останавливает только отсутствие поддержки андроида
Хотел спросить, чем плох вот этот плагин: https://github.com/jvoegele/gradle-android-plugin/wiki/
Обратите внимание на то, что многие задачи были отмечены 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 — то вот небольшое сравнение.

Решать вам.
Хочу сделать запускаемый jar-файл, требуемые бибилиотеки к которому прописаны в манифесте через classpath. Как-то так:

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

}
Чего вы от меня ожидали? С Groovy почти не знаком, не говоря уже о Gradle.
Дорогу осилит идущий… это я к тому, что со временем получится и более грамотный скрипт.
Ну уж, «хана». Человек попробовал. И получил требуемый результат.
Возможно, это стоило бы сделать подругому. Я бы, к примеру, перенёс этот код внутрь task'a «jar». А вы?
Я не об этом. Пример чётко показывает, что люди начинают сразу же колошматить свои «анто-велосипеды». Главная мысль мавена ведь: 1 проект -> 1 артифакт + дока + тесты + конфиг, то есть — берёшь человека на работу, а ему знакома уже эта конструкция. Что мы видем из выше изложенного: берём человека на работу и начинается почему-так-и-почему-не-этак-и-как-это-работает-вообще (не Gradle, а build проекта).

пс: 2 раза толстой книгой по рукам! +))
Блин, какой кошмар! Полная свобода действий — это конечно же круто, но где в проекте вы видели только спецов? Это ведь будет выглядеть так же, как «чёрт-его-знает-какие-ант-скрипты-в-которых-уже-не-понять-что-к-чему». То есть, на эту штуку нужно сажать архитектора и билд-менеджера, а другим просто лупить толстой книгой по рукам!
В принципе да, так и есть. Частично от этого предохраняет активное использование Convention-over-Configuration. Частично — дисциплина :)

На maven тоже можно такого наворотить — сам черт не разберёт :)
Думаю, что зря драматизируете.
Чем подход к написанию билд-скриптов отличается от обычного программирования? Никто не отменял простейших принципов разумности, понятности, простоты кода.

Из всего можно сделать говно.
Only those users with full accounts are able to leave comments. Log in, please.