我已经使用Maven好几个月了,我对它的工作方式非常满意
在概念上和实践中。
我还对Buckminster进行了广泛的研究(但还没有运行示例)来尝试找出它是什么。
以及如何比较。该文档很差。例如,他们使用诸如“构建自动化”和“部署”之类的术语,但我尚未看到有关部署的任何信息。分阶段迁移是另一个未曾暗示但尚未讨论的话题。
Maven和Buckminster都使您能够指定依赖项,并通常管理构建,测试和可能的部署过程。
它们都具有eclipse集成,并且都应该(仅使用过Maven)简化基于eclipse的项目及其依赖项的设置和共享。
我可以看到的主要区别是:
从我的角度来看,我想与Buckminster一起做的大部分事情都可以与Maven一起做。来自版本控制的“ Material 化”是一个加号,但是组织内的开发人员除了提供固定版本外,还可以将maven快照发布到存储库以彼此共享。
Maven生命周期的束缚似乎确实具有更大的灵活性和自由度(曾经想添加另一个阶段,如清理后测试?必须等待他们在核心中进行)。
我想念什么? Buckminster中是否有一些重要的功能值得复杂化?
上面是否有任何荒谬的陈述(假设我不是Buckminster用户,而只是中低级Maven用户)?
最佳答案
一些澄清。
Buckminster没有自己的存储库类型。它具有发现机制,可以将现有的元数据(例如Maven POM)转换为Buckminster可以理解的模型。如果无法以任何其他方式派生该元数据,则可以将其作为XML文件逐字添加。
Buckminster决定以与Eclipse IDE相同的方式构建内容。除此之外,它还从 list ,build.properties,plugin.xml等已知工件中提取信息,并将其转换为模型中可以使用Buckminster perform命令显式触发的 Action 。
我完全不相信Buckminster会为无头建筑携带更多行李。实际上,我认为相反的情况更为普遍。即使手头的任务很琐碎,在空机器上使用Maven进行构建通常也要从大量组件的下载开始。
Buckminster基于OSGi,并使用Eclipse扩展点进行了扩展。可以使用这种机制添加新的存储库类型,新的操作类型,新的发现机制等。
最低的Buckminster配置仅需要一个CQUERY和一个RMAP。有了它们,就有可能构建一个完整大小的完整p2更新站点,并用pack200对其进行签名和处理。无需将文件添加到任何功能和 bundle 包。不需要“降级”。所以我不确定我是否同意Maven更易于配置。
除了Roland和Zoltán已经提到的好处外,我还要补充一点,因为buckminster构建是一个真正的工作区构建,所以它将利用.project文件中声明的所有构建器。以下是一些示例: