Замена build.xml на Build.java - использование библиотек Java и Ant в качестве системы сборки

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

Вам может потребоваться некоторый клей Ant XML, чтобы делать такие вещи, как компиляция самих сценариев сборки и фактический вызов java для выполнения сборки, но это второстепенно.

Java не только более читабельна, чем Ant, особенно когда дело касается условного выполнения, но и намного быстрее. Наша сборка на основе Ant раньше занимала минуту или около того, чтобы собрать EAR, теперь версия на основе java занимает около 5 секунд.

У вас была прекрасная идея. У Cliff Click была похожая идея: http://blogs.azulsystems.com/cliff/2008/01/i-hate-makefile.html.

Если вы пройдете через это, я советую вам сделать его как можно более простым, чтобы ваша система сборки не нуждалась в самой [нетривиальной] системе сборки.

Учитывая, что Java скомпилирована, это своего рода проблема курицы и яйца. Вам необходимо создать свой Build.java, чтобы построить свой проект.

В настоящее время Ant поддерживает встроенные сценарии с использованием BeanShell, Groovy и ряда других, что действительно может помочь уменьшить потребность в этом.

РЕДАКТИРОВАТЬ: В ответ на многочисленные комментарии Дина, если ваша сборка состоит строго из длинного цикла, то вам действительно не нужен скрипт сборки ant. Однако сила сценария сборки заключается в том, что он гарантирует, что зависимости выполняются только один раз, при этом допускаются множественные точки входа, что далеко не тривиально, если вы откатываете свои собственные.

Если вам не нравится формат XML, вы не одиноки, с вами согласен автор ANT. Однако, если ваш взгляд на процесс сборки - это то, что можно запустить из вашей IDE в качестве единственной точки запуска, я бы сказал, что ваши потребности сборки довольно просты.

EDIT2: я поддержал ответ skaffman, потому что он напрямую связан с вопросом. В комментариях мы, кажется, согласны с тем, что подход хорош для процедурной сборки, но не будет работать для декларативной, и что вам понадобится хотя бы немного ANT xml, чтобы начать работу с вашим Build.java, чтобы избежать курицы и проблема с яйцом. Похоже, в этом вся суть дела.

Здесь, кажется, потерялся важный момент.

Ant написан на Java, и я ищу лучший способ использовать задачи Ant (API в библиотеках Ant), чем через xml. На всю жизнь я не понимаю, как использование xml для вызова Java когда-либо было бы лучше или проще, чем использование Java для вызова Java.

Единственным препятствием является то, что подход xml документирован, тогда как подход Java не документирован, поэтому мне придется загрузить и ознакомиться с кодом Ant.

Я воздерживался от публикации этого вопроса в течение нескольких недель, потому что был уверен, что кто-то делал это раньше и что мой google-foo просто нуждается в улучшении. Использование Java для вызова API-интерфейсов Ant вместо xml кажется настолько очевидным, что я все еще удивлен, что для Ant не было разработано параллельного подхода на основе Java, а также подхода xml.

Однако то, что это очевидно, не означает, что кто-то делал это раньше.

Хотя я полагаю, что это возможно, вам, вероятно, было бы лучше использовать сценарии оболочки, чем писать полную программу на Java, чтобы просто автоматизировать сборки.

Вы бы упустили одно из ключевых применений ant, а именно простые для задания наборы файлов и легкие для чтения в свойствах.

Я застрял на ant, поскольку Groovy слишком близок к написанию всего приложения, чтобы просто создать ваше настоящее приложение. Слишком сложно для неприятностей.

Хотя использовать задачи Ant внутри программ Java довольно просто, на вашем месте я бы, вероятно, придерживался файлов сборки Ant. Если вы занимаетесь отличной разработкой, если Eclipse не делает то, что вам нужно, возможно, вам нужно поискать в другом месте (IntelliJ, NetBeans и т. Д.).