Подтвердить что ты не робот

Зачем выбирать Бакминстера над Мейвеном?

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

Я также довольно подробно рассмотрел Buckminster (но еще не получил пока образцы), чтобы попытаться выяснить, что это такое и как он сравнивается. Документация оставляет желать лучшего. Например, они используют терминологию типа "Автоматизация сборки" и "Развертывание", но я все еще ничего не вижу о развертывании. Поэтапная миграция - еще одна намеченная, но не обсуждаемая тема.

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

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

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

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

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

  • Сложение

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

  • Плагины

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

  • Развертывание

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

  • Сложность

    • Различные схемы для Buckminster могут быть довольно сложными, между CPECs RMAPs MSPEC и т.д.
    • Maven несколько проще в настройке, хотя он может стать сложным с большими и многомодульными проектами. У Maven также есть архетипы для легкого создания новых проектов.

  • Документация

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

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

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

Что мне не хватает? Есть ли в Бакминстере какие-то большие функциональные возможности, которые стоят сложнее?

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

4b9b3361

ОТВЕТЫ

Ответ 1

Некоторые пояснения.

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

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

  • Построить

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

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

  • Плагины

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

  • Сложность

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

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

  • PDE Manifest builder - генерирует предупреждения и ошибки из манифеста, файлов свойств и т.д.
  • Конструктор схем PDE (то же самое для схем точек расширения)
  • Все другие строители, созданные для структуры Eclipse Build. Это включает в себя построители проверки схемы XML, конструкторы Java Script и многие другие.
Я уверен, что у Maven есть переписка для большинства из них. Дело с Бакминстером в том, что вам не нужно поддерживать дополнительную систему сборки. Что работает в рабочей области IDE, также работает без головного убора.

Ответ 2

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

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

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

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

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

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

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

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

Ответ 3

Существует книга Бакминстера в формате PDF, доступная на странице загрузки Бакминстера - более 250 страниц документации и включает в себя как вводную, так и подробную справочную документацию.

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

Ответ 4

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

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

Ответ 5

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

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

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

У меня нет опыта в данный момент с Tycho, но это кажется многообещающим.

Ответ 6

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

Я бы лично не хотел связывать мой процесс сборки с Eclipse или любой другой IDE. Есть много преимуществ, позволяющих выполнять полную сборку из инструмента командной строки без необходимости использования IDE или другого инструмента GUI.

Бесплатная книга O'Reilly Maven: The Definitive Guide великолепно написана и действительно заполняет недостаток документации Maven.

Ответ 7

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

Я использовал Ralf tutorial, чтобы получить хороший обзор по теме.

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

Как настроить Hudson и Buckminster можно прочитать в учебнике Ralf. Маленький совет, чтобы предотвратить OutOfMemoryErrors, добавьте -Xmx1024m к "дополнительные параметры" вашей установки в Бакминстере (см. устранение неполадок Hudson из памяти).

У меня есть отдельная работа в свободном стиле для публикации моей целевой платформы для другие рабочие места. В разделе "Управление исходным кодом" я проверяю функция, которая содержит мое целевое определение (в моем случае 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&

Создание продукта

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

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

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