Самый тривиальный пример — генерация дополнительных мета-файлов.
Второй вариант — более распроастранённый — это сборка в «нестандартную» структуру. В нашем maven-проекте, например, есть огромные вставки Ant скриптов просто потому, что тот jar который получается должен содержать в себе особенную структуру (Видимо так было сделать прощем, чем писать плагины для Maven). А ещё какую то часть кода мы компилируем Java 1.4, а другую Java 1.5, и ещё какую то часть пропускаем через обфускатор, некоторые jar-ы сливаем воедино, а некоторые упаковываем во внутренний каталог; итд.
В целом же, даже если мы будем говорить о стандартной сборке, то Gradle уделывает Maven как стоячего, за исключением, конечно, поддержки со стороны IDE. Уделывает как в простоте описания проекта, так и с большой вероятностью в скорости самой сборки.
23derevo
А зачем делать нестандартные вещи в Maven? Антон, можешь пример привести, где мавен не канает?
Антон Архипов
Самый тривиальный пример — генерация дополнительных мета-файлов.
Второй вариант — более распроастранённый — это сборка в «нестандартную» структуру. В нашем maven-проекте, например, есть огромные вставки Ant скриптов просто потому, что тот jar который получается должен содержать в себе особенную структуру (Видимо так было сделать прощем, чем писать плагины для Maven). А ещё какую то часть кода мы компилируем Java 1.4, а другую Java 1.5, и ещё какую то часть пропускаем через обфускатор, некоторые jar-ы сливаем воедино, а некоторые упаковываем во внутренний каталог; итд.
В целом же, даже если мы будем говорить о стандартной сборке, то Gradle уделывает Maven как стоячего, за исключением, конечно, поддержки со стороны IDE. Уделывает как в простоте описания проекта, так и с большой вероятностью в скорости самой сборки.
michael
зачем компилировать что то в 1.4 а что то в 1.5?
Антон Архипов
специфика продукта