当前位置： 文江博客话题详情

为什么选择 Buckminster 而不是 Maven？

发布于 2024-07-13 21:38:56 字数 2071 浏览 11 评论 0原文

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

我还广泛地研究了 Buckminster （但尚未运行示例）来尝试计算知道它是什么 以及比较如何。 文档很差。 例如，他们使用“构建自动化”和“部署”等术语，但我还没有看到任何有关部署的信息。 分阶段迁移是另一个暗示但未讨论的话题。

Maven 和 Buckminster 都使您能够指定依赖项并通常管理构建、测试和可能的部署过程。

它们都具有 Eclipse 集成，并且都应该（仅使用 Maven）简化基于 Eclipse 的项目及其依赖项的设置和共享。

我可以看到的主要区别是：

  • 依赖关系：

    • Buckminster 除了能够引用 Maven 存储库的依赖项之外，还可以指定源存储库及其自己类型的存储库中的依赖项。
    • Buckminster 可以将依赖项分组到虚拟发行版中，并且还具有平台感知能力。 在 Maven 中，通过引用其他依赖项并对它们进行分组的 pom，软件的分组显然是可能的。

  • 构建

    • Maven 使用基于布局的隐式构建系统。 创建默认项目、将内容放在预期的位置并使用 Maven 构建、测试和创建 jar 非常容易。 同时，含蓄也可能会受到限制。 您必须接受 Maven 的工作方式。
    • Buckminster - 我不清楚 Buckminster 如何决定构建什么以及如何构建它。 看起来这将与 Eclipse 过程保持一致，以实现相同的目的。 Buckminster 还允许使用 ant，但尚不清楚这是否是一项要求。 至少，生命周期的好坏定义较少（未？），从而提供了更大的灵活性。
    • 这两种工具都允许无头构建，尽管巴克明斯特可能会带来更多的负担。

  • 插件

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

  • 部署

    • Maven 有许多插件，用于生成软件分发（程序集）并移动它们（货车）。 巴克明斯特是否从 Ant 那里得到了这一切？

  • 复杂性

    • Buckminster 的不同模式可能非常复杂，在 CPEC、RMAP、MSPEC 等之间。
    • Maven 在配置方面稍微简单一些，尽管大型多模块项目可能会变得复杂。 Maven 还具有原型，可以轻松创建新项目。

  • 文档

    • 他们都很糟糕。 ;-)
    • Buckminster 在文档方面非常肤浅。 没有足够的示例。
    • Maven 插件的文档往往很差，因此很难让它们正确运行。

从我的角度来看，我想用 Buckminster 做的大部分事情都可以用 Maven 来做。 版本控制的“具体化”是一个优点，但组织内的开发人员除了提供固定版本之外，还可以将 Maven 快照发布到存储库以相互共享。

Maven 生命周期的限制似乎确实更加灵活和自由（曾经想要添加另一个阶段，比如清理后测试？必须等待他们在核心中完成）。

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

上面是否有任何非常不准确的陈述（假设我不是 Buckminster 用户，而只是中低级别的 Maven 用户）？

原文

I've been using Maven for several months and I am pretty comfortable with how it works
conceptually and in practice.

I have also looked at Buckminster quite extensively (but have not gotten to running samples yet) to try and figure out what it is
and how it compares. The documentation is poor. For instance, they use terminology like Build Automate and Deploy, but I have yet to see anything about deployment. Staged-migration is another hinted-at but un-discussed topic.

Both Maven and Buckminster give you the ability to specify dependencies and generally manage the build, test and possibly deploy processes.

They both have eclipse integration and should both (having only used Maven) trivialize the setup and sharing of eclipse based projects and their dependencies.

The major differences that I can see are:

  • Dependencies:

    • Buckminster can specify dependencies living in source repositories and it's own type of repository in addition to being able to reference Maven repositories for dependencies.
    • Buckminster can group dependencies into virtual distros and is also platform aware. The grouping of software certainly seems possible in Maven with poms that reference other dependecies and group them.

  • Build

    • Maven uses an implicit build system based on layout. It is very easy to create a default project, put things where they are expected to be and have maven build, test and create jars. At the same time, being implicit can also be constricting. You have to live with how Maven does things.
    • Buckminster - It is not clear to me how Buckminster decides what to build and how to build it. It would seem that this would align with the eclipse process for doing the same. Buckminster also allows the use of ant, but it is not clear if this is a requirement. At the very least, the lifecycle is less (un?) defined for good or bad, allowing more flexibility.
    • Both tools allow for headless builds, although buckminster may carry a bit more baggage along with it.

  • Plugins

    • Maven has a very extensive set of plugins for all phases of the lifecycle for many different kinds of automation, from code generation to running embedded services for testing.
    • Buckminster does not appear to have the same concept of plugins. There are readers and actors, but they do not seem to play the same role. Buckminster should have access to the extensive set of plugins available for ant. It is not clear how well ant actions can be seamlessly integrated with the rest of Buckminster processes (this is also an issue for the maven ant plugin).

  • Deployment

    • Maven has a number of plugins for generating distributions of software (assemblies) and moving them around (wagons). Does Buckminster get all of this from Ant?

  • Complexity

    • The different schemas for Buckminster can be quite complex, between CPECs RMAPs MSPECs, etc.
    • Maven is somewhat simpler configuration-wise, although it can get complex with large and multi-module projects. Maven also has Archetypes for easy creation of new projects.

  • Documentation

    • They are both bad. ;-)
    • Buckminster is very shallow, documentation-wise. Not enough examples are available.
    • Maven plugins tend to have very poor documentation, making it difficult to get them running correctly.

From my perspective, most of what I would want to do with Buckminster I can do with Maven. "Materializing" from version control is a plus, but developers within an organization can publish maven snapshots to a repository to share with each other, in addition to just providing fixed versions.

There does seem to be more flexibility and freedom from the strictures of the Maven lifecycle (ever wanted to add another phase, like post-test for cleanup? Gotta wait for them to do it in the core).

What am I missing? Is there some major amount of functionality in Buckminster that is worth the step up in complexity?

Are there any wildly innacurate statements above (given that I am not a Buckminster user and only a low-mid level Maven user)?

如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论， 你可以免费 注册 一个本站的账号。

评论（7）

不及他 2024-07-20 21:38:56

一些澄清。

  • 依赖关系

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

  • 构建

    Buckminster 决定构建什么，就像 Eclipse IDE 一样。 除此之外，它还从已知工件（例如清单、build.properties、plugin.xml 等）中提取信息，并将其转换为模型中可以使用 Buckminster Perform 命令显式触发的操作。

    我一点也不相信巴克明斯特为无头构建带来了更多包袱。 事实上，我认为相反的情况更为常见。 在空机器上使用 Maven 进行构建通常会从下载大量组件开始，即使手头的任务很微不足道。

  • 插件

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

  • 复杂

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

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

  • PDE Manifest 构建器 - 从清单、属性文件等生成警告和错误。
  • PDE Schema 构建器（与扩展点模式相同）
  • 针对 Eclipse Build 结构制作的所有其他构建器。 这包括 XML 模式验证构建器、Java 脚本构建器以及许多其他构建器。

I'm sure that Maven has correspondence for a majority of them. The point with Buckminster is that you don't need to maintain an extra build system. What works in the IDE workspace, also works headlessly.

Some clarifications.

  • Dependencies

    Buckminster does not have a repository type of its own. It has a discovery mechanism that translates existing meta-data such as a Maven POM into a model that can be understood by Buckminster. This meta-data can be added verbatim as an XML file if it cannot be derived in any other way.

  • Build

    Buckminster decides what to build the same way the Eclipse IDE does. In addition to that it extracts information from known artifacts such as the manifest, build.properties, plugin.xml etc. and translates it into actions in the model that can be explicitly triggered using the Buckminster perform command.

    I'm not at all convinced that Buckminster carries more baggage for headless builds. In fact, I think the opposite is more common. Building with Maven on an empty machine often starts with a download of a very large number of components even if the task at hand is trivial.

  • Plugins

    Buckminster is based on OSGi and extended using Eclipse Extension points. It is possible to add new types of repositories, new types of actions, new discovery mechanisms, and more using this mechanism.

  • Complexity

    A minimum Buckminster configuration only needs one CQUERY and an RMAP. With them, it is possible to build a full p2 update site of arbitrary size that is signed and processed with pack200. No files needs to be added to any of the features and bundles. Nothing needs to be "Buckminsterized". So I'm not sure I agree that Maven is simpler to configure.

Aside from the benefits already mentioned by Roland and Zoltán, I'd like to add that since the buckminster build is a true workspace build, it will leverage all builders that have been declared in the .project file. Here are some examples:

  • PDE Manifest builder - generates warnings and errors from manifests, property files, etc.
  • PDE Schema builder (same thing for Extension point schemas)
  • All other builders made for the Eclipse Build structure. This includes XML schema validation builders, Java Script builders, and many many others.

I'm sure that Maven has correspondence for a majority of them. The point with Buckminster is that you don't need to maintain an extra build system. What works in the IDE workspace, also works headlessly.

回复 原文
英雄似剑 2024-07-20 21:38:56

Maven 使用隐式构建系统
基于布局。 这很容易
创建一个默认项目，放东西
他们预计会在哪里并且已经在哪里
Maven 构建、测试和创建 jar。 在
同时，隐式也可以
受到限制。 你必须和
Maven 如何做事。

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

巴克明斯特 - 我不清楚
巴克明斯特如何决定建造什么
以及如何构建它。 看上去
这将与日食保持一致
执行相同操作的过程。
巴克明斯特还允许使用
蚂蚁，但不清楚这是否是蚂蚁
要求。 至少，
生命周期的定义较少（未？）
好或坏，允许更多
灵活性。

我认为 Maven 倾向于遵循明智的默认值的哲学，而这些默认值很容易被覆盖。

Maven 稍微简单一些
配置方面，虽然它可以
变得复杂大和
多模块项目。 梅文也有
轻松创建新的原型
项目。

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

文档：它们都不好。 ;-)

不能不同意这一点！

Maven uses an implicit build system
based on layout. It is very easy to
create a default project, put things
where they are expected to be and have
maven build, test and create jars. At
the same time, being implicit can also
be constricting. You have to live with
how Maven does things.

Actually, you can explicitly specify where you put things in Maven. The default locations are just that, defaults, easy to override, though there's rarely a good reason to.

Buckminster - It is not clear to me
how Buckminster decides what to build
and how to build it. It would seem
that this would align with the eclipse
process for doing the same.
Buckminster also allows the use of
ant, but it is not clear if this is a
requirement. At the very least, the
lifecycle is less (un?) defined for
good or bad, allowing more
flexibility.

I think Maven tends to follow the philosophy of sensible defaults which are easily overrode.

Maven is somewhat simpler
configuration-wise, although it can
get complex with large and
multi-module projects. Maven also has
Archetypes for easy creation of new
projects.

Maven's real strength is in its management of dependencies and this tends to shine particularly well in complex projects with multiple subprojects. It's pretty easy to define a hierarchy of subprojects and have it just work.

Documentation: They are both bad. ;-)

Can't disagree with that!

回复 原文
国产ˉ祖宗 2024-07-20 21:38:56

巴克明斯特下载页面提供了 PDF 格式的巴克明斯特书籍 - 超过 250 页的文档，包括介绍和详细的参考文档。

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

There is a Buckminster Book in PDF available from the Buckminster Download page - more than 250 pages of documentation and includes both introduction and detailed reference documentation.

Download it from here: http://www.eclipse.org/downloads/download.php?file=/tools/buckminster/doc/BuckyBook.pdf

回复 原文
你没皮卡萌 2024-07-20 21:38:56

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

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

The biggest advantage of using Buckminster is when compiling OSGi bundles or Eclipse plug-ins, because it can reuse the PDE build infrastructure, that handles all kinds of versioning information already present in the manifest.mf/plugin.xml files. When using Maven, this information has to be duplicated (AFAIK). If you don't develop Eclipse plug-ins, and are already familiar with Maven, then Buckminster will offer no real advantage, especially considering the steep learning curve. On the other hand for building Eclipse plug-ins it offers better ot-of-the-box support.

You can extend Buckminster by writing new readers (to obtain source from other locations) or new actors (that provide build steps - these actors can reuse Maven or Ant, thus providing extra functionality).

回复 原文
撩动你心 2024-07-20 21:38:56

我想知道为什么没有人提到第谷。 Tycho 已被提议作为 Eclipse 项目，现在位于 孵化阶段。

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

  • 正如所提到的，巴克明斯特的文档非常糟糕。
  • 事实上，我从来没有运行过巴克明斯特的例子。
  • 我了解 Maven，恕我直言，文档比巴克明斯特的更好。
  • 我想使用构建服务器（Jenkins）并且Maven的集成非常好。

目前我还没有使用第谷的经验，但它看起来很有希望。

I wonder why nobody mentioned Tycho. Tycho has been proposed as Eclipse Project and now in Incubating Phase.

I tried to get along with Buckminster but I will now have a look at Tycho. This has the following reasons:

  • As mentioned the documentation of buckminster is really bad.
  • Actually I never got one of the buckminster examples running.
  • I know Maven and the documentation is IMHO better than buckminster's.
  • I want to use an build server (Jenkins) and the integration of Maven is quite good.

I have no experience at the moment with Tycho, but it seems promising.

回复 原文
心的位置 2024-07-20 21:38:56

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

我个人不想将我的构建过程与 Eclipse 或任何其他 IDE 联系起来。 能够从命令行工具执行完整构建而不需要 IDE 或其他 GUI 工具有很多好处。

免费的 O'Reilly 书籍 Maven：权威指南 写得非常出色并真正填补了 Maven 文档的空白。

My (extremely limited) understanding of Buckminster in a nutshell is that it is a system for versioning and sharing Eclipse project configurations for a set of projects among team members. It does seem to overlap with Maven in that it manages dependencies, but I think these are Eclipse project level dependencies and not java dependencies.

I would personally not want to tie my build process to Eclipse or any other IDE. There are a lot of benefits to being able to perform a full build from a command line tool without the need for an IDE or some other GUI tool.

The free O'Reilly book Maven: The Definitive Guide is superbly written and really fills in the Maven documentation gap.

回复 原文
懒的傷心 2024-07-20 21:38:56

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

我使用Ralf 的教程来很好地了解该主题。

目标平台

如何设置 Hudson 和 Buckminster 可以在 Ralf 的教程中阅读。
小提示，为了防止 OutOfMemoryErrors，请将 -Xmx1024m 添加到
Buckminster 安装的“附加参数”（请参阅
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 +数字+插件
在
集成作业我选择“创建格式化版本号”将其命名
“version”并使用类似 I${BUILD_YEAR, XXXX}${BUILD_MONTH, XX}${BUILD_DAY, XX}-${BUILDS_TODAY} 作为格式。

为了最终构建客户端产品，我添加了巴克明斯特构建步骤，
选择之前发布的目标平台并使用
以下为命令：

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 在bundle manifest 中定义。

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

Due to lack of buckminster documentation I created an example of a Building Products with Buckminster/Hudson. This may help to get started, also works with Jenkins.

I used Ralf's tutorial to get an good overview about the topic.

Target Platform

How to setup Hudson and Buckminster can be read in Ralf's tutorial.
Little tip, to prevent OutOfMemoryErrors, add -Xmx1024m to the
"additional parameters" of your Buckminster installation (see
troubleshooting tip Hudson out of memory).

I have a separated free style job to publish my target platform for
other jobs. In the "Source-Code-Management" section I checkout the
feature which contains my target definition (in my case
ch.scodi.client.site).
To actually resolve the target definition, I
added a build step "Run Buckminster" with the following command:

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

In the Post-Build-Action checked "Archive and publish an Eclipse
Target Platform" and added
.metadata/.plugins/org.eclipse.pde.core/.bundle_pool as path.

Consider that the TargetDefinition can not resolve directory
locations. My target definition used to have a directory location
containing bundles from the springsource repository.
I tried using the
rmap file to get the bundles during materialization but had some
trouble with that, so I decided to create an own update site for those
bundles and add this site to the target definition. More on that can
be found here:
http://www.eclipse.org/forums/index.php?t=msg&th=164508&start=0&

Building the Product

After the target definition job is run, we can start building the
products.
This is pretty straight forward, see Ralf's tutorial on how
to checkout your source from SVN.
I have three different builds for
each, server and client product: Integration, Nightly and Release.
For
each build the plug-in qualifier should be different (e.g.
I20100326-2, N20100326, R20100326-01). To accomplish this I installed
the flowing plug-in:
http://wiki.hudson-ci.org/display/HUDSON/Version+Number+Plugin
In the
integration job I choose "Create a formatted version number" name it
"version" and use something like this I${BUILD_YEAR, XXXX}${BUILD_MONTH, XX}${BUILD_DAY, XX}-${BUILDS_TODAY} as format.

To finally build the client product I added a Buckminster build step,
selected the previously published target platform and used the
following as commands:

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

Notice qualifier.replacement.*=${version}, this tells
Buckminster/Eclipse to use my formatted version as qualifier and
results in plug-ins named like this
com.softmodeler.model_1.0.0.I20100325-3.jar, requires that
Bundle-Version: 1.0.0.qualifier is defined in the bundle manifest.

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

回复 原文
~没有更多了~

关于作者

懒的傷心

暂无简介

0 文章
0 评论
23 人气
发私信

相关话题

更多

热门标签

操作系统 程序设计 IT运维 Linux系统管理 JavaScript 服务器应用 solaris C/C++ PHP Shell BSD Vue.js aix Oracle Python HTML 系统管理 HTML5 CSS 前端
更多

推荐作者

胡图图

文章 0 评论 0

zt006

文章 0 评论 0

z祗昰~

文章 0 评论 0

冰葑

文章 0 评论 0

野の

文章 0 评论 0

天空

文章 0 评论 0

更多

友情链接

文江博客
    我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站，即表示您同意使用 Cookies 和您的相关数据。
    原文