为什么选择Buckminster而不是Maven？

时间：2009-02-23 22:13:21

标签： java maven-2 build-automation buckminster

我已经使用Maven几个月了，我对它的运作方式非常满意 在概念上和实践中。

我也非常广泛地看了Buckminster（但尚未运行样本）试图找出它是什么 以及它如何比较。文档很差。例如，他们使用Build Automate和Deploy等术语，但我还没有看到有关部署的任何信息。分阶段迁移是另一个暗示但尚未讨论的主题。

Maven和Buckminster都能让您指定依赖关系，并且通常可以管理构建，测试和可能的部署过程。

他们都有eclipse集成，并且两者都应该（仅使用Maven）使基于eclipse的项目及其依赖项的设置和共享变得无足轻重。

我能看到的主要区别是：

  • 依赖关系：

    • 除了能够引用Maven存储库以获取依赖关系之外，Buckminster还可以指定存储在源存储库中的依赖项以及它自己的存储库类型。
    • Buckminster可以将依赖关系分组为虚拟发行版，也可以识别平台。在Maven中，软件分组似乎是可能的，其中poms引用其他依赖并将它们分组。

  • 构建

    • Maven使用基于布局的隐式构建系统。创建一个默认项目非常容易，把它放在预期的位置，并有maven构建，测试和创建jar。同时，隐含也可以是收缩。你必须忍受Maven如何做事。
    • Buckminster - 我不清楚Buckminster如何决定构建什么以及如何构建它。似乎这会与日食过程一致。巴克敏斯特也允许使用蚂蚁，但目前尚不清楚这是否是一项要求。至少，生命周期较少（不？）定义为好或坏，允许更大的灵活性。
    • 这两种工具都允许无头构建，尽管巴克敏斯特可能携带更多行李。

  • 插件

    • Maven为生命周期的各个阶段提供了非常广泛的插件集，适用于许多不同类型的自动化，从代码生成到运行嵌入式服务进行测试。
    • Buckminster似乎没有相同的插件概念。有读者和演员，但他们似乎没有扮演同样的角色。 Buckminster应该可以访问可用于ant的大量插件。目前尚不清楚ant动作能够与其他Buckminster进程无缝集成（这也是maven ant插件的一个问题）。

  • 部署

    • Maven有许多插件用于生成软件（程序集）的分发并移动它们（货车）。 Buckminster是否从Ant获得所有这些？

  • 复杂性

    • Buckminster的不同模式在CPECs RMAPs MSPEC等之间可能相当复杂。
    • Maven在配置方面稍微简单一些，尽管它可能会因大型和多模块项目而变得复杂。 Maven还拥有Archetypes，可以轻松创建新项目。

  • 文档

    • 他们都很糟糕。 ; - ）
    • 巴克敏斯特非常浅，文档方面。没有足够的例子。
    • Maven插件往往文档很差，很难让它们正常运行。

从我的角度来看，我想用Buckminster做的大部分事情都可以和Maven一起使用。从版本控制“物化”是一个优点，但组织中的开发人员可以将maven快照发布到存储库以便彼此共享，此外还提供固定版本。

似乎有更多的灵活性和自由度来避免Maven生命周期的限制（曾经想要添加另一个阶段，比如后期测试以进行清理？必须等待他们在核心中执行此操作。）

我错过了什么？ Buckminster中是否有一些重要的功能值得提高复杂性？

上面是否有任何非常真实的声明（鉴于我不是Buckminster用户，只有中低级别的Maven用户）？

7 个答案:

答案 0 :(得分：10)

一些澄清。

  • 依赖

    Buckminster没有自己的存储库类型。它有一个发现机制，可以将现有的元数据（如Maven POM）转换为Buckminster可以理解的模型。如果无法以任何其他方式导出，则可以将此元数据逐字添加为XML文件。

  • 构建

    Buckminster以与Eclipse IDE相同的方式决定构建内容。除此之外，它还从已知工件中提取信息，例如manifest，build.properties，plugin.xml等，并将其转换为模型中可以使用Buckminster perform命令显式触发的操作。

    我完全不相信巴克明斯特为无头建筑带来了更多的包袱。事实上，我认为相反的情况更为常见。在空机器上使用Maven构建通常从下载大量组件开始，即使手头的任务很简单。

  • 插件

    Buckminster基于OSGi并使用Eclipse扩展点进行扩展。可以使用此机制添加新类型的存储库，新类型的操作，新的发现机制等。

  • 复杂性

    最小Buckminster配置只需要一个CQUERY和一个RMAP。有了它们，就可以构建一个任意大小的完整p2更新站点，该站点使用pack200进行签名和处理。不需要将任何文件添加到任何功能和包中。没有什么需要“Buckminsterized”。所以我不确定我是否同意Maven配置更简单。

除了Roland和Zoltán已经提到的好处之外，我想补充一点，因为buckminster构建是一个真正的工作区构建，它将利用在.project文件中声明的所有构建器。以下是一些示例：

  • PDE清单构建器 - 从清单，属性文件等生成警告和错误。
  • PDE架构构建器（扩展点架构的相同内容）
  • 为Eclipse Build结构制作的所有其他构建器。这包括XML模式验证构建器，Java Script构建器以及许多其他构建器。
我确信Maven对其中的大多数都有通信。 Buckminster的观点是您不需要维护额外的构建系统。在IDE工作区中有效的方法也可以无头工作。

答案 1 :(得分：7)

  

Maven使用隐式构建系统   基于布局。这很容易   创建一个默认项目，放东西   他们应该在哪里   maven构建，测试和创建jar。在   同时，隐含也可以   收缩。你必须忍受   Maven如何做事。

实际上，您可以明确指定在Maven中放置内容的位置。默认位置只是默认值，易于覆盖，但很少有充分的理由。

  巴克敏斯特 - 我不清楚   巴克敏斯特如何决定建造什么   以及如何建立它。这似乎   这将与日食一致   做同样的过程。   巴克敏斯特也允许使用   蚂蚁，但目前尚不清楚这是否是一个   需求。至少，   生命周期较少（不？）定义为   好与坏，允许更多   灵活性。

我认为Maven倾向于遵循容易过度的合理违约理念。

  

Maven有点简单   配置方面，虽然它可以   复杂的大和   多模块项目。 Maven也有   Archetypes轻松创建新的   项目

Maven的真正优势在于对依赖关系的管理，这在具有多个子项目的复杂项目中尤为明显。定义子项目的层次结构并使其正常工作非常容易。

  

文档：它们都很糟糕。 ; - ）

不能不同意！

答案 2 :(得分：7)

Buckminster下载页面提供了一个PDF格式的Buckminster书籍 - 超过250页的文档，包括介绍和详细的参考文档。

从这里下载：http://www.eclipse.org/downloads/download.php?file=/tools/buckminster/doc/BuckyBook.pdf

答案 3 :(得分：5)

使用Buckminster的最大优势是编译OSGi包或Eclipse插件时，因为它可以重用PDE构建基础结构，该基础结构处理manifest.mf / plugin.xml文件中已存在的各种版本信息。使用Maven时，必须复制此信息（AFAIK）。如果您不开发Eclipse插件，并且已经熟悉Maven，那么Buckminster将没有真正的优势，特别是考虑到陡峭的学习曲线。另一方面，为了构建Eclipse插件，它提供了更好的开箱即用支持。

您可以通过编写新的读者（从其他位置获取源代码）或新的actor（提供构建步骤 - 这些actor可以重用Maven或Ant，从而提供额外的功能）来扩展Buckminster。

答案 4 :(得分：3)

我想知道为什么没有人提到Tycho。 Tycho被提议为Eclipse Project，现在是Incubating Phase。

我试图与巴克明斯特相处，但我现在看看第谷。这有以下原因：

  • 如前所述，巴克敏斯特的文档非常糟糕。
  • 实际上我从来没有运行过一个buckminster示例。
  • 我认识Maven并且文档比笨蛋更好恕我。
  • 我想使用构建服务器（Jenkins），并且Maven的集成非常好。

目前我对Tycho没有任何经验，但似乎很有希望。

答案 5 :(得分：2)

我对Buckminster的理解（极其有限）简单来说，它是一个系统，用于在团队成员之间为一组项目进行版本控制和共享Eclipse项目配置。它似乎与Maven重叠，因为它管理依赖项，但我认为这些是Eclipse项目级依赖项，而不是Java依赖项。

我个人不想将构建过程绑定到Eclipse或任何其他IDE。无需IDE或其他GUI工具即可从命令行工具执行完整构建，这有很多好处。

免费的O'Reilly书籍Maven: The Definitive Guide编写得非常出色，真正填补了Maven文档的空白。

答案 6 :(得分：0)

由于缺少buckminster文档，我创建了一个使用Buckminster / Hudson构建产品的示例。这可能有助于入门，也适用于 Jenkins 。

  

我使用Ralf's tutorial来详细了解该主题。

     

目标平台

     

如何设置Hudson和Buckminster可以在Ralf的教程中阅读。   小提示，为防止OutOfMemoryErrors，添加-Xmx1024m   ＆＃34;其他参数＆＃34;您的Buckminster安装（请参阅   troubleshooting tip Hudson out of memory）。

     

我有一个单独的自由风格作业来发布我的目标平台   其他工作。在＆＃34;源代码管理＆＃34;第一节结帐   功能包含我的目标定义（在我的情况下   ch.scodi.client.site）。
为了实际解决目标定义，我   添加了构建步骤＆＃34;运行Buckminster＆＃34;使用以下命令：

     

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

     

在构建后操作已选中＆＃34;存档并发布Eclipse   目标平台＆＃34;并补充说   .metadata/.plugins/org.eclipse.pde.core/.bundle_pool作为路径。

     

考虑TargetDefinition无法解析目录   位置。我的目标定义曾经有一个目录位置   包含来自泉源库的包。
我尝试使用   rmap文件在实现过程中获取bundle但有一些   麻烦，所以我决定为那些创建一个自己的更新站点   捆绑并将此站点添加到目标定义。更多关于那可以   在这里找到：
  http://www.eclipse.org/forums/index.php?t=msg&th=164508&start=0&

     

构建产品

     

运行目标定义作业后，我们可以开始构建   产品。
这很简单，请参阅Ralf关于如何使用的教程   从SVN检查你的来源。
我有三个不同的版本   每个，服务器和客户端产品：集成，每晚和发布。
For   每个构建插件限定符应该是不同的（例如   I20100326-2，N20100326，R20100326-01）。为此，我安装了   流动的插件：
  http://wiki.hudson-ci.org/display/HUDSON/Version+Number+Plugin
  我选择的集成工作＆＃34;创建格式化的版本号＆＃34;说出来   ＆＃34;版本＆＃34;并使用类似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

相关问题
最新问题