Информация по Gradle

Bogdan Shyiak SE or Dev 27.12.2011 21:05

С мавеном какая история:
1) На сколько я понял он требует жесткой структуры исходников (по слухам пути переопределять напряжно и не факт что потом можно будет нормально с ними работать). Проект старый и со своей «особенной» (странной) структурой.
2) Есть кастомные ант-таски. Не хотелось бы получить смесь мавена и анта.
3) Далеко не всем нравится декларативный стиль и ХМЛ.

4) Управление зависимостями так же можно прикрутить. Да и в общем для новых проектов градл похож на «мавен без ХМЛя».

Теперь собственно с чего решили переходить:

Вкрутить в сборку нормальную сборку (та что сейчас нормальная, но все-таки «на троечку») джаваскриптов и прочей статики. Готовых решений не нашел, прийдется писать код, а оформлять в виде кастом-тасков анта и не помню как они называются в мавене, немного не удобно. Но может я чего-то не знаю? Если у вас есть предложения, готов выслушать.

Против мавена ничего лично не имею, если у вас есть аргументы «за» с интересом выслушаю.

Sergey Ponomarev

Andriy Dobrov 27.12.2011 21:15

Может я неправильно вас понял но:
a) мавен ассемблер плагин должен очень помочь
b) если хорошо понимаете структуру проекта :) то можно сборку делать в 2 шага:
— подготовка к сборке (на основании вашего старого проекта построить проект более заточенный на тот же мавен) ант тут удобнее с его тасками
— собственно сборка мавен

Bogdan Shyiak SE or Dev 27.12.2011 21:30

a) мавен ассемблер плагин должен очень помочь

Не совсем понимаю, если не трудно дайте пару ссылок.

b) если хорошо понимаете структуру проекта :)

К сожалению не очень.

то можно сборку делать в 2 шага

Так сборка и так длинная.

Основная проблема:

Есть места которые по другому как кодом не решишь. Интрефейс ант-таксов не удобен: вместо скрипта приходится писать по факту программу (или компонент). Если я правильно понял, то Mojo не сильно отличаются в этом плане.

Andriy Dobrov

Andriy Dobrov 27.12.2011 21:40

maven.apache.org/...ples/index.html
я говорил о другом. Я как раз говорил о том что на первом шаге преобразовать проект в структуру близкую к мавен требуемой а на втором шаге без проблем собрать

первый шаг можно реализовать ант вкусностей (копирование, аплоад/даунлоад файлов, вызова скриптов или написания груви кода внутри таски)

все это реализовать за тем же ант фасадом (вызывая мавен из анта)

Bogdan Shyiak SE or Dev 27.12.2011 21:45

Спасибо, посмотрю подробнее.

Если я вас правильно понял, то таки получится на выходе микс анта и мавена, поддерживаемость которого прямо пропорционально прямоте рук того кто будет переводить?

Andriy Dobrov

Andriy Dobrov 27.12.2011 21:48

Богдан получается стандартная задача на преобразование и как всегда якобиан преаобразования никто не отменял :) вот просто работавших с ант людей довольно много да исам ант не есть рокет саентс

Sergey Ponomarev Java & Grails Developer 27.12.2011 21:32

все пункты решимы или терпимы.

Bogdan Shyiak SE or Dev 27.12.2011 21:41

так я и не против.

А про терпимость, так и ант терпим :)

Sergey Ponomarev

Sergey Ponomarev Java & Grails Developer 27.12.2011 21:51

Сори у меня нет времени на развёрнутый камент, да и опыта прям оп всем пунктам, поэтому отсылаю к докладу Лёхи Солнцева «maven уличная магия».
Но в целом:
1) Да, так и есть но тут с грейдлом явно ещё сложнее будет.
2) Прийдётся, но мавеновские плагины перекрывают почти все нужные антовские таски
3) Декларативный стиль это то к чему стремится эволюция ЯП. XML не страшен. А с хорошей IDE вообще на ура. Можно использовать Groovy вместо него.

4) Управление зависимостями через мавен работает на ура в IDE. Про груви я написал выше.

Вообщем мавен мавен мавен

Bogdan Shyiak SE or Dev 27.12.2011 22:38

к докладу Лёхи Солнцева «maven уличная магия»

Я его слышал. Но может так слушал, но основное что я услышал:

Если к вас правильна структура — все круто, если нет — сделайте «правильную структуру» и будет все круто. Основная проблема в том что приводить к «правильной структуре» в данном случае проблематично.