Что вы используете для сложного процесса сборки?

Ответ 1

За исключением Ant, о котором вы указали, и для плавного make/autotools, основными инструментами являются:

• SCons
• Jam
• CMake
• Maven

Я использую SCons, потому что это основанный на python, хорошо финансируемый и элегантный. Кажется, что застревание является наиболее прагматичным. Я не слишком много знаю о CMake. Maven может быть для вас выбором, поскольку он является ориентированным на Java и более высоким уровнем, чем Ant.

Подробнее вы можете найти в wikipedia: Список встроенных инструментов

Ответ 2

Если вы преследуете Maven, тогда у вас будут две проблемы: сложная сборка и изучение f @* # ing "магии" Maven. Maven только делает проблему хуже, потому что она тупо и слишком сложна.

Я унаследовал устаревшую сборку Maven 1.x в крупной компании из списка Fortune 500. В последние годы я использовал Maven 2.x по многим другим проектам. Я оценил Маэстро, надеясь, что это может сделать Maven приемлемым. Мой вывод, как и многие другие народы (проверьте "сеть" ), заключается в том, что Maven - это большой шаг в неправильном направлении. Это определенно не улучшение по сравнению с Ant.

Я использовал Ant для MANY years, включая запись большой библиотеки с открытым исходным кодом из Ant вспомогательных скриптов. Я также широко использовал своего кузена .NET nAnt. Однако Ant имеет два основных недостатка. Во-первых, XML просто не подходит для выполнения задач сборки. Два, Ant и XML недостаточно хорошо масштабируются для больших сложных сборок. На самом деле, я много написал здесь в SO о своих впечатлениях на этой арене (и с Maven).

Лидеры отрасли пришли к выводу, что сборка - это просто еще одно приложение, к которому нужно обратиться с помощью общих инструментов приложения. Однако, поскольку он включает в себя функциональность на уровне системы и кросс-платформу, большинство языков/платформ разработки не подходят (включая Java и, следовательно, Ant и Maven). Это также исключает .NET.

Я потратил два года на поиск альтернативы, и я нашел это: Python. Он имеет правильную комбинацию системного доступа, кросс-платформенной переносимости, простоты, удобочитаемости, мощности, надежности и зрелости. SCons, buildbot, setuptools/easyinstall и базовый Python - моя текущая целевая платформа для процесса сборки. При необходимости интеграции с Ant, Maven и любым другим таким инструментом легко. Между тем, я могу использовать эти инструменты для ядра любой сборки на любой платформе с любым исходным языком. Больше никаких препятствий, не более сумасшедшая сложность, не более предположительно-полезный "декларативный" сценарий, не более черный ящик f @* # ing "magic".

Если вы не можете переключиться на Python, попробуйте Ant + Ivy (на apache.org). Это дает вам Maven классный репозиторий без большинства зол Maven. Именно это я и делаю, когда это необходимо и целесообразно.

С наилучшими пожеланиями.

Ответ 3

Также посмотрите

• Gant
• Gradle

В то время как более общие системы сборки, такие как SCons, очень мощные, поддержка Java несколько ограничена по сравнению с системами, специально предназначенными для создания Java-проектов.

Ответ 4

Мне нравится использовать Rake, так как вы можете вернуться к силе целого Ruby язык и библиотека фреймворка при необходимости.

Ответ 5

Я использую Ant, используя макрос. Если вы планируете свой проект в постоянном mannner, вы можете устранить много дублирования, написав макросы.

Я создавал Antlib, содержащий макросы и пользовательские задачи, которые я повторно использую для нескольких проектов.

В качестве альтернативы, некоторые люди клянутся Maven. Другие люди просто клянутся в Maven.

Ответ 6

Я использую Maven, а не только для сборки, я также использую их модуль release/dist.

В паре команд я могу иметь код, который был в исходном элементе управления для сборки, упаковки и выпуска.

Плагин release управляет обновлением номеров версий, dist справляется с тем, как собрать все вместе и закрепить его.

Ant выглядит тяжело по сравнению с Maven. Конечно, есть кривая обучения с Maven, но чтение pom.xml намного проще, чем чтение build.xml.

Maven должен быть гораздо менее подробным.

Ответ 7

Мне нравится Ant, но только если вы тратите время на создание собственных плагинов Java для инкапсуляции сложных действий. Это не сложно, но, к сожалению, большинство людей пытаются написать свою логику в XML с помощью ant -contrib stuff. Я думаю, что это огромная ошибка.

Я слышал хорошие вещи о rake и инструментах groovy (упомянутых в другом комментарии), но у меня нет опыта с ними.

Если вы пытаетесь выполнить script несколько шагов в жизненном цикле, вам может быть лучше использовать сервер сборки на основе автоматизации процесса, такой как AnthillPro (Cruise, BuildForge и Electric-Commander - другие в этом пространстве).

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

(Я организатор для CITCON, но работа любви не является производителем прибыли. У этого действительно есть действительно полезный список рассылки. Если бы я был сутенер за деньги, это было бы The CI Guys.;-))

Ответ 8

Придерживайтесь Ant, поскольку вы создаете Java. Я смешал Ant/SCons для какой-либо работы JNI, но в целом я остался бы с Ant тем более, что у вас есть существующая установка сборки в Ant. Портирование на Maven будет похоже на то, чтобы прорезать квадратную привязку через стену без отверстий.

Объявите свою собственную логику Java для любого и рассмотрите возможность написания правильных Ant задач вместо выполнения внешнего Java-кода. Я решил некоторые очень сложные части нашего процесса сборки, просто расширив Ant, чтобы сделать именно то, что мне нужно, например. управлять ресурсами значков для большого проекта gui или вводить информацию о подрывной деятельности непосредственно информацию jar manifestests (спасибо SVNKit)

Ответ 9

Я бы пошел с Ant в любой день недели.

Это не идеально; XML очень многословный, и реализация любой логики практически невозможна, но даже самый младший инженер в команде может по крайней мере понять, что делает файл Ant в течение дня.

Сложная логика может быть реорганизована с использованием java и интегрирована в ant, если вы этого пожелаете. Ant дает вам всю мощь java:)

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

У меня также есть некоторый опыт работы как с Maven 1, так и с Maven 2. Этот опыт оставил мне ощущение, что Maven - потрясающий проект для хобби, но может иметь сложности для программного обеспечения, которое необходимо поддерживать с течением времени.

Я вижу две важные проблемы с Maven:

• Любая зависимость, которую вы импортируете с помощью Maven, может со временем меняться, не зная об этом, что приводит к странным проблемам.
• Вы импортируете лицензии не только программного обеспечения, которое вы импортируете напрямую, используя Maven, но и лицензии, используемые библиотеками, которые косвенно импортированы.

Короче говоря, мне не нравится тот факт, что сборка зависит от времени ее запуска. Это может быть настоящей проблемой при выпуске исправления ошибок через год после выпуска продукта.

Разумеется, эти проблемы могут управляться (возможно, с использованием прокси-сервера nexus), но вам нужно рассмотреть их перед восстановлением системы сборки. В моей компании мы решили использовать Ant для всех новых проектов и пытаться переносить maven 1 и 2 на Ant всякий раз, когда появляется это событие. Слишком сложно поддерживать работу.

Мой совет, если вы и ваша команда знаете, как обращаться с ant, попробуйте реорганизовать ваш файл Ant и не переходите на какой-либо другой инструмент сборки. Это занимает слишком много времени, чтобы понять это правильно; время, которое вы могли бы потратить на зарабатывание денег и выживание в качестве компании:)

Ответ 10

Мы используем luntbuild. Это веб-приложение, которое очень простое в использовании. Он будет проверять CVS/SVN, автоматически увеличивать номер версии/сборки, выполнять задачи сборки в сценариях ant и пометить ваш репозиторий новой версией. Можно запланировать автоматические сборки, отправить их вам по электронной почте или связаться с вами через IM, а также иметь зависимости безопасности и сборки.

Мы по-прежнему используем версию 1.2.3, но я вижу ее до 1.6.0. Он просто работает.

http://luntbuild.javaforge.com/

EDIT: перечитав ваш вопрос, я вижу теперь, что вы ищете что-то для замены Ant. В нашем случае ant на самом деле не проблема. У нас есть проекты в Netbeans, которые используют ant для построения, и нам просто нужно реализовать некоторые перехватчики в существующих сценариях, предоставляемых Netbeans, что очень легко сделать.

EDIT: Похоже, вы можете вызвать ant из Groovy. Это было бы хорошо, потому что тогда вы можете повторно использовать все задачи, которые уже существуют для Ant.

http://groovy.codehaus.org/Using+Ant+from+Groovy

Ответ 11

Я использую Rake везде, где только могу. Если вам нужно создать java-код, вы можете использовать его с jruby или посмотреть на что-то вроде: buildr

Ответ 12

Попробуйте FinalBuilder

Он предоставляет интерфейс GUI для любого процесса сборки и имеет собственное действие практически для всего, плюс студию действий, в которой вы можете создать свой собственный.

С небольшим количеством планирования можно очень упростить.

Ответ 13

Мне нужно добавить к этому одному решению, которое, как мне кажется, не может жить без... его называемого Hudson. Для настройки требуется всего несколько секунд, и вы обычно можете уйти с большей частью из ваших существующих файлов ANT.

Кроме того, Hudson предоставляет отличный способ создания "cron", выполнения тестовых примеров и генерации "артефактов" (например, сборки продуктов) таким образом, чтобы каждый мог скачать.

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

Ответ 14

Maven - действительно хороший выбор, чтобы делать большие сборки... в большинстве случаев, когда он не работает, очень просто. Люди неправильно понимают концепции Мавена. Если вы работаете с "maven way", вы получите более мелкие модули, которые позволят вам улучшить архитектуру вашего программного обеспечения. С другой стороны, такие вещи, как Hudson, помогут вам сократить время сборки, используя Maven, заставляя Hudson поддерживать только измененные модули, которые не поддерживаются никаким другим инструментом сборки. Проблема с Maven заключается в том, чтобы изучить и понять концепции Maven, например, структуру проекта (папки и т.д.) Или только один артефакт и т.д. Цикл сборки будет поддерживать вас в разных областях: компиляция, упаковка, развертывание и выпуск который не поддерживается другими инструментами (только если вы его реализуете вручную). Я написал много больших скриптов Ant, чтобы достичь этого). Другие проблемы, такие как изменения с течением времени, вызваны игнорированием передового опыта и которые используются.

Ответ 15

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

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

https://github.com/edertone/TurboBuilder