Открыть список
Как стать автором
Обновить

Комментарии 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
НЛО прилетело и опубликовало эту надпись здесь
под андроидом я хотел сказать Android SDK, для layoutopt он используется
Groovy совсем не конкурент Scala. А вот их комбинация как скриптового и основного языка — это уже интересно.
groovy++ — вполне себе потенциальный и очень сильный конкурент
Частично согласен, но это пока не очень популярная ветка и так не очень популярного языка. ;)
на фоне скалы это уже достаточно много ;)
:) Scala имеет непопулярность лишь первого порядка.
а расскажите какие ниши они занимают?
Scala — это естественный заменитель Java + мощный язык для написания действительно сложных вещей.

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

Если речь идет о скриптах, то уже давно есть интерпретатор Java — BeanShell
на groovy можно писать синтасисом java'ы, но зачем?
Одна из ключевых особенностей 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/
уже не работает, увы :(
см. issues
Обратите внимание на то, что многие задачи были отмечены 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 тоже можно такого наворотить — сам черт не разберёт :)
Думаю, что зря драматизируете.
Чем подход к написанию билд-скриптов отличается от обычного программирования? Никто не отменял простейших принципов разумности, понятности, простоты кода.

Из всего можно сделать говно.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.