Почему стоит выбрать Бакминстер вместо Maven? - PullRequest
21 голосов
/ 24 февраля 2009

Я использую Maven в течение нескольких месяцев, и мне довольно удобно, как это работает концептуально и на практике.

Я также достаточно подробно рассмотрел Бакминстер (но еще не пробовал запускать сэмплы), чтобы попытаться выяснить, что это такое. и как это сравнивается. Документация плохая. Например, они используют терминологию, такую ​​как Build Automate и Deploy, но я еще ничего не видел в развертывании. Поэтапная миграция - еще одна подсказка, но не обсуждаемая тема.

И Maven, и Buckminster дают вам возможность указывать зависимости и в целом управлять процессами сборки, тестирования и, возможно, развертывания.

Они оба имеют интеграцию Eclipse и должны оба (используя только Maven) упрощать настройку и совместное использование проектов на основе Eclipse и их зависимостей.

Основные различия, которые я вижу:

  • Зависимости:

    • Buckminster может указывать зависимости, живущие в исходных репозиториях, и свой собственный тип репозитория в дополнение к возможности ссылаться на репозитории Maven для зависимостей.
    • Buckminster может группировать зависимости в виртуальные дистрибутивы, а также поддерживает платформу. Группировка программного обеспечения, безусловно, представляется возможной в Maven с помпами, которые ссылаются на другие зависимости и группируют их.
  • Строить

    • Maven использует неявную систему сборки на основе компоновки. Очень легко создать проект по умолчанию, поместить вещи туда, где они должны быть, и собрать maven, протестировать и создать jar-файлы. В то же время, неявность может также ограничивать. Вы должны жить с тем, как Maven делает вещи.
    • Бакминстер - мне не ясно, как Бакминстер решает, что строить и как его строить. Казалось бы, это согласуется с процессом затмения для того же. Бакминстер также допускает использование муравья, но не ясно, является ли это требованием. По крайней мере, жизненный цикл менее (не?) Определен как хороший или плохой, что обеспечивает большую гибкость.
    • Оба инструмента допускают сборку без головы, хотя бакинстер может нести с собой немного больше багажа.
  • Плагины

    • Maven имеет очень обширный набор плагинов для всех этапов жизненного цикла для самых разных видов автоматизации, от генерации кода до запуска встроенных сервисов для тестирования.
    • Бакминстер, похоже, не имеет той же концепции плагинов. Есть читатели и актеры, но они, похоже, не играют одинаковой роли. Buckminster должен иметь доступ к обширному набору плагинов, доступных для ant. Непонятно, насколько хорошо действия ant могут быть легко интегрированы с остальными процессами Buckminster (это также проблема для плагина maven ant).
  • Развертывание

    • Maven имеет несколько плагинов для генерации дистрибутивов программного обеспечения (сборок) и перемещения их (вагонов). Бакминстер получает все это от муравья?
  • Сложность

    • Различные схемы для Бакминстера могут быть довольно сложными, между CPEC, RMAP, MSPEC и т. Д.
    • Maven несколько проще в настройке, хотя он может усложняться в больших и многомодульных проектах. Maven также имеет Архетипы для легкого создания новых проектов.
  • Документация

    • Они оба плохие. ; -)
    • Бакминстер очень поверхностный, с точки зрения документации. Недостаточно примеров.
    • Плагины Maven обычно имеют очень плохую документацию, что затрудняет их правильную работу.

С моей точки зрения, большую часть того, что я хотел бы сделать с Бакминстером, я могу сделать с Maven. «Материализация» из контроля версий - это плюс, но разработчики в организации могут публиковать моментальные снимки maven в репозитории, чтобы делиться ими друг с другом, в дополнение к предоставлению только фиксированных версий.

Кажется, что существует большая гибкость и свобода от ограничений жизненного цикла Maven (когда-нибудь хотел добавить еще одну фазу, например, после тестирования для очистки? Должен ждать, пока они сделают это в ядре).

Что мне не хватает? Есть ли в Buckminster какой-то значительный объем функциональности, который стоит увеличить по сложности?

Существуют ли какие-либо крайне неточные утверждения выше (учитывая, что я не пользователь Бакминстера, а только пользователь Maven низкого и среднего уровня)?

Ответы [ 7 ]

10 голосов
/ 28 апреля 2010

Некоторые уточнения.

  • Зависимость

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

  • Сложение

    Buckminster решает, что делать так же, как и в Eclipse IDE. В дополнение к этому он извлекает информацию из известных артефактов, таких как манифест, build.properties, plugin.xml и т. Д., И преобразует ее в действия в модели, которые можно явно инициировать с помощью команды Buckminster execute.

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

  • Плагины

    Buckminster основан на OSGi и расширен с использованием точек расширения Eclipse. Используя этот механизм, можно добавлять новые типы репозиториев, новые типы действий, новые механизмы обнаружения и многое другое.

  • Сложность

    Минимальная конфигурация Buckminster требует только одного CQUERY и RMAP. С их помощью можно создать полноценный сайт обновлений p2 произвольного размера, подписанный и обработанный с помощью pack200. Нет необходимости добавлять файлы в какие-либо функции и пакеты. Ничто не должно быть "Buckminsterized". Поэтому я не уверен, что согласен с тем, что Maven проще в настройке.

Помимо преимуществ, уже упомянутых Роландом и Золтаном, я хотел бы добавить, что, поскольку сборка buckminster является истинной сборкой рабочей области, она будет использовать все компоновщики, которые были объявлены в файле .project. Вот несколько примеров:

  • PDE Manifest builder - генерирует предупреждения и ошибки из манифестов, файлов свойств и т. Д.
  • Построитель схем PDE (то же самое для схем точек расширения)
  • Все остальные строители сделаны для структуры Eclipse Build. Это включает в себя компоновщики валидации XML-схем, компоновщики Java Script и многие другие.
Я уверен, что Maven имеет переписку для большинства из них. Суть в Buckminster в том, что вам не нужно поддерживать дополнительную систему сборки. То, что работает в рабочей области IDE, также работает без головы.
7 голосов
/ 28 апреля 2010

На странице загрузки Buckminster можно найти книгу Buckminster Book в формате PDF - более 250 страниц документации, включающую как вводную, так и подробную справочную документацию.

Загрузите его отсюда: http://www.eclipse.org/downloads/download.php?file=/tools/buckminster/doc/BuckyBook.pdf

7 голосов
/ 24 февраля 2009

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

На самом деле, вы можете явно указать, куда вы помещаете вещи в Maven. Местоположения по умолчанию - это просто настройки по умолчанию, которые легко переопределить, хотя редко есть веская причина.

Бакминстер - мне не понятно как Бакминстер решает, что строить и как его построить. Казалось бы что это будет соответствовать затмению Процесс для того же. Бакминстер также позволяет использовать муравей, но не ясно, если это требование. По крайней мере, жизненный цикл меньше (не?) определен для хорошо или плохо, позволяя больше гибкость.

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

Maven несколько проще в конфигурации, хотя это может получить комплекс с большим и многомодульные проекты. Maven также имеет Архетипы для легкого создания новых проекты.

Настоящая сила Maven заключается в управлении зависимостями, и это особенно хорошо проявляется в сложных проектах с несколькими подпроектами. Довольно легко определить иерархию подпроектов и заставить ее работать.

Документация: они оба плохие. ; -)

Не могу с этим не согласиться!

5 голосов
/ 09 марта 2010

Самым большим преимуществом использования Buckminster является компиляция пакетов OSGi или плагинов Eclipse, поскольку он может повторно использовать инфраструктуру сборки PDE, которая обрабатывает все виды информации о версиях, уже присутствующей в файлах manifest.mf / plugin.xml. При использовании Maven эта информация должна дублироваться (AFAIK). Если вы не разрабатываете подключаемые модули Eclipse и уже знакомы с Maven, то Бакминстер не предложит никаких реальных преимуществ, особенно с учетом крутой кривой обучения. С другой стороны, для создания плагинов Eclipse предлагается лучшая поддержка «из коробки».

Вы можете расширить Buckminster, написав новых читателей (для получения источника из других мест) или новых актеров (которые предоставляют этапы сборки - эти актеры могут повторно использовать Maven или Ant, что обеспечивает дополнительную функциональность).

3 голосов
/ 12 июля 2011

Интересно, почему никто не упомянул Тихо . Tycho был предложен как Eclipse Project и теперь Фаза инкубации .

Я пытался ладить с Бакминстером, но теперь я посмотрю на Тихо. Это имеет следующие причины:

  • Как уже упоминалось, документация Бакминстера действительно плохая.
  • На самом деле, я никогда не запускал один из примеров Бакминстера.
  • Я знаю Мэйвена, и документация ИМХО лучше, чем у Бакминстера.
  • Я хочу использовать сервер сборки (Jenkins), и интеграция Maven довольно хорошая.

У меня нет опыта работы с Тихо, но это выглядит многообещающе.

2 голосов
/ 26 февраля 2009

Мое ( крайне ограниченное ) понимание Бакминстера в двух словах заключается в том, что это система управления версиями и совместного использования конфигураций проектов Eclipse для набора проектов среди членов команды. Кажется, что он частично совпадает с Maven в том смысле, что он управляет зависимостями, но я думаю, что это зависимости уровня проекта Eclipse, а не зависимости java.

Лично я бы не хотел связывать процесс сборки с Eclipse или любой другой IDE. Возможность выполнения полной сборки из инструмента командной строки дает массу преимуществ без необходимости в IDE или каком-либо другом инструменте с графическим интерфейсом.

Бесплатная книга О'Рейли Maven: Полное руководство великолепно написано и действительно заполняет пробел в документации Maven.

0 голосов
/ 02 сентября 2016

Из-за отсутствия документации Бакминстера я создал пример Building Products с Buckminster / Hudson . Это может помочь начать работу, также работает с Jenkins .

Я использовал Учебник Ральфа , чтобы получить хороший обзор по теме.

Целевая платформа

Как настроить Хадсона и Бакминстера, можно прочитать в руководстве Ральфа. Небольшой совет, чтобы предотвратить ошибки OutOfMemory, добавьте -Xmx1024m к «дополнительные параметры» вашей установки Buckminster (см. совет по устранению неполадок Хадсону не хватает памяти ).

У меня есть отдельная бесплатная работа для публикации моей целевой платформы для другие работы. В разделе «Управление исходным кодом» я извлекаю функция, которая содержит мое определение цели (в моем случае ch.scodi.client.site).
Чтобы на самом деле решить определение цели, я добавил шаг сборки "Run Buckminster" с помощью следующей команды:

importtargetdefinition -A '${WORKSPACE}ch.scodi.client.site/TargetDefinition.target'

В Post-Build-Action отмечено "Архивировать и публиковать Eclipse" Целевая платформа "и добавил .metadata/.plugins/org.eclipse.pde.core/.bundle_pool как путь.

Учтите, что TargetDefinition не может разрешить каталог местах. У моего определения цели раньше был каталог содержащий пакеты из хранилища springsource.
Я пытался использовать Файл rmap для получения пакетов во время материализации, но имел некоторые проблемы с этим, поэтому я решил создать собственный сайт обновления для тех, связать и добавить этот сайт в определение цели. Подробнее об этом можно найти здесь:
http://www.eclipse.org/forums/index.php?t=msg&th=164508&start=0&

Построение продукта

После запуска задания определения цели мы можем приступить к созданию продукты.
Это довольно просто, см. учебник Ральфа о том, как чтобы проверить ваш источник из SVN.
У меня есть три разных сборки для каждый, серверный и клиентский продукт: интеграция, ночной и выпуск.
Для каждая сборка спецификатора плагина должна быть разной (например, I20100326-2, N20100326, R20100326-01). Для этого я установил плавный плагин:
http://wiki.hudson -ci.org / display / HUDSON / Версия + Номер + Плагин
В задание интеграции я выбираю «Создать отформатированный номер версии» "version" и используйте что-то вроде I${BUILD_YEAR, XXXX}${BUILD_MONTH, XX}${BUILD_DAY, XX}-${BUILDS_TODAY} в качестве формата.

Для окончательной сборки клиентского продукта я добавил шаг сборки Buckminster, выбрал ранее опубликованную целевую платформу и использовал следующие как команды:

import '${WORKSPACE}source/scodi-rcp/features/ch.scodi.client.site/site.cquery'

build

perform -D target.os=* -D target.ws=* -D target.arch=* -D
qualifier.replacement.*=${version} ch.scodi.client.site#site.p2.zip
perform -D target.os=win32 -D target.ws=win32 -D target.arch=x86
ch.scodi.client.site#create.product.zip perform -D target.os=win32 -D
target.ws=win32 -D target.arch=x86_64
ch.scodi.client.site#create.product.zip

Обратите внимание qualifier.replacement.*=${version}, это говорит Buckminster / Eclipse, чтобы использовать мою отформатированную версию в качестве классификатора и в результате плагины названы так com.softmodeler.model_1.0.0.I20100325-3.jar, требует, чтобы Bundle-Version: 1.0.0.qualifier определяется в комплекте manifest.

http://flaviodonze.blogspot.ch/2010/03/building-products-with.html

...