2010-08-22 7 views
5

Лучший инструмент для построения Java, который я знаю до сих пор, кажется, является maven,Есть ли инструмент, похожий на cmake для Java?

, но он по-прежнему не дает такой гибкости, как cmake вообще!

Кто-нибудь знает инструмент cmake-like для java?

+0

Я хотел бы спросить это на stackoverflow.com – Unfundednut

ответ

2

Это, вероятно, лучший вопрос для stacoverflow.com, но я бы порекомендовал Ant. Он очень прочный и гибкий.

1

Ant и maven - слишком большие инструменты для сборки. С maven, если вы хотите делать пользовательские сборки, вам, скорее всего, придется писать свой собственный плагин maven, который не так уж тяжело. Для создания собственного плагина существует множество документации в Интернете. Приятная вещь о создании плагина maven заключается в том, что его легко разделить в организации или с командой разработчиков; действительно разделяйте эти плагины, вам, как правило, необходимо разместить свое собственное maven-репо.

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

Ivy - еще один популярный инструмент сборки, однако у меня нет опыта с ним.

+0

Плющ не является инструментом Buld, это просто инструмент управления зависимость, которая играет очень хорошо с муравей (обеспечивает встроенную поддержку для него). –

2

Лучший строительный инструмент для Java Я знаю до сих пор, кажется, Maven, но она по-прежнему не дает столько гибкости, как CMake на всех!

Возможно, это правда, но я бы спросил, действительно ли вам нужна эта «гибкость». Частью самой большой ценности maven является то, что она стандартизирует разработку. Способ управления источниками/ресурсами, зависимость, четко определенные жизненные циклы и т. Д. И т. Д.

Именно из-за этой стандартизации вы можете легко подключить серверы сборки, IDE, автоматические инструменты для тестирования и многие другие инструменты. Также важно, что новым разработчикам проще познакомиться с базой кода, потому что они знают, какую структуру ожидать.

Эти преимущества будут потеряны, если у вас есть «гибкая» сборка, однако, вы действительно получите что-нибудь от такой «гибкой» сборки? Многие люди используют maven, и почти для всех проблем они уже создали решение. Если вы попытаетесь использовать эти стандартизованные решения, у вас будет меньше проблем с построением IMHO.

Если у вас есть редкая ситуация, в которой вам действительно нужно что-то сделать, что невозможно сделать стандартным образом, вы все равно можете использовать скрипты/ant-задачи и т. Д. В maven и даже писать собственные плагины. Но я действительно сомневаюсь, что вам когда-нибудь понадобится это сделать.

-1

CMake не имеет понятия зависимостей (только от зависимостей источников от объектных файлов или разделяемых библиотек), но не от уровня артефакта (например, jar's в Java) или RPM и т. Д. Я бы назвал это зависимостями модуля. У CMake нет понятия транзитивных зависимостей и т. Д. У CMake нет понятия определенной структуры проекта (Конвентная конфигурация). У CMake нет понятия репозитория (например, у Maven). CMake не поддерживает интегрированные тесты Unit/Integration. Нет определенного жизненного цикла сборки. У CMake нет концепции управления выпуском (у которой есть maven) и т. Д.

but it still doesn't give so much flexibility as cmake at all! 

Что именно вы пропустите здесь, в Maven?

+0

Забавно, как люди могут смотреть на одну и ту же реальность и видеть совершенно противоположные вещи. «Создание концепции» всех этих вещей - именно то, что делает ее менее гибкой: вы не можете отклоняться от концепций Maven't или легко добавлять новые. Принимая во внимание, что CMake позволяет вам делать абсолютно что угодно, но все вместе работать становится все сложнее, чем сложнее сборка. –

+1

Гибкость, о которой вы говорите, делает сборку в большом проекте беспорядком (создайте отдельный проект разработки: сборка), вы получите большую гибкость, чем у вас есть. У Maven достаточно гибкости, чтобы сделать это. Могут быть ситуации, когда вы достигаете предела, но тогда вы можете просто создать плагин. Вы говорите, что можете сделать абсолютное что угодно легко? Хм ... Это означает, что с другой стороны, вы должны сами определять эти или подобные концепции, сначала в проекте, и это требует много времени. – khmarbaise

+0

@khmarbaise: Отсутствие гибкости делает строительство большого проекта беспорядок, потому что авторы Maven не могут удовлетворить каждый проект (на самом деле, Maven хорош только для маленьких игрушечных проектов). Пользовательские плагины - это трудный путь достижения простых целей, которые вы можете выполнить с помощью простых сценариев оболочки. И зависимости ... ну, есть несколько хороших примеров из истории, таких как менеджеры пакетов Linux. И все же разработчики игрушек Maven полностью ввернули его в худший возможный путь. Вызов этого «менеджера зависимостей» является оскорблением для менеджеров пакетов REAL. И управление выпуском - просто приятное модное слово. Я могу писать несколько строк. – woky

Смежные вопросы