在使用Maven开发OSGi应用程序时,我应该先使用POM还是先使用清单?
使用Maven开发OSGi应用程序时,有两种主要方法:POM优先和MANIFEST优先 我正在寻找一个以表格的形式给出的答案,该表格显示了每种方法的优缺点 更具体地说,我还想知道它与以下方面的关系:在使用Maven开发OSGi应用程序时,我应该先使用POM还是先使用清单?,maven,osgi,tycho,maven-bundle-plugin,Maven,Osgi,Tycho,Maven Bundle Plugin,使用Maven开发OSGi应用程序时,有两种主要方法:POM优先和MANIFEST优先 我正在寻找一个以表格的形式给出的答案,该表格显示了每种方法的优缺点 更具体地说,我还想知道它与以下方面的关系: 工具集的成熟度 供应商独立性 开发简易性(包括寻找能够在工具上进行开发的人员) 相容性 避免类未找到 避免体力劳动 目前这是我能想到的 POM第一职业(使用maven bundle插件) 利用现有的Maven技能、存储库和工具 可能更容易找到知道如何管理pom.xml的人,而不是MANIFEST
- 工具集的成熟度
- 供应商独立性
- 开发简易性(包括寻找能够在工具上进行开发的人员)
- 相容性
- 避免类未找到
- 避免体力劳动
- 利用现有的Maven技能、存储库和工具
- 可能更容易找到知道如何管理pom.xml的人,而不是MANIFEST.MF和pom.xml
- MANIFEST.MF中的大部分信息都可以从pom.xml本身获得
- 可以与其他IDE协作,而不仅仅是基于Eclipse的IDE
- 侵入性较小,只需添加单个插件,并将包装类型更改为“bundle”
更可能在运行时发生。然而,这可以通过pax考试来缓解(尽管设置起来非常复杂)ClassNotFoundException
- 仍然需要了解清单是如何设置的,以确保正确设置了
配置元素李>说明
- 似乎是推荐的方法,或者至少被称为推荐的方法,但我真的不明白为什么它有显著的好处。(因此提出这个问题的原因)
- 适合开发Eclipse插件,并与PDE很好地集成
- 提供测试工具,从而允许在JUnit测试期间而不是运行时出现
ClassNotFoundException
- 似乎只有在基于Eclipse的IDE上才能很好地工作。您不必使用Eclipse,但是如果没有PDE,您会想要吗
- 违反了DRY原则,因为我必须将POM和MANIFEST.MF中的名称和版本保持同步
- 需要以特定的方式命名事物
- 您不能混合使用,这意味着现有的Maven多项目安装不能仅仅依靠OSGi支持
- 与maven bundle插件相比,需要更多的配置才能获得更少的警告:
- 必须将测试用例作为一个单独的项目。它在src/test/java中构建时不会运行
- 似乎它只测试公开的类,换句话说,“.internal.”中的类是不可测试的
如果我被要求为正在进行Eclipse插件开发的人提供一个建议,那么它是先显式的——而tycho不会先显式地将您锁定在Eclipse上(尽管我会感到惊讶,如果超过少数人会使用其他任何东西)。清单是重要的文件,无论您如何操作,都需要添加到jar中 另一方面,POM首先将您完全锁定在Maven上,这样您就失去了一个优势,即OSGi捆绑包是一个普通的jar,您可以按照自己的方式制作 我两个都试过了,我真的更喜欢先看清单。清单文件是一个非常重要的文件,我更喜欢手工制作该文件,而不是手工制作生成该文件的文件。如果发生了奇怪的事情,(并且在某个时候会发生),清单文件是第一个要检查的文件,如果它是您自己的文件,那么就更容易了。此外,无论如何你都必须熟悉它
因此,如果Maven是您的alpha和omega,POM first将最适合您,但您仍然需要深入了解清单文件。我认为您应该根据用例进行选择。对于服务器端OSGi项目,我倾向于pom优先样式。它与maven构建非常匹配,并且比Manifest first更不容易出错。 事实上,maven bundle插件背后的bnd在大多数情况下都可以获得正确的清单,而不需要任何额外的配置。诀窍是使用一些命名规则。例如,如果命名为internal package impl或internal,则不会导出。使用这种风格,你不能使用Eclipse插件透视图(至少没有我不喜欢的bndtools),但我还没有错过这个透视图。我是ApacheKaraf、CXF和Camel项目的开发人员,我们在这些项目中使用这种风格,效果非常好。特别是对于CXF和Camel,我们可以使用相同的构建和工具支持OSGi和非OSGi部署,这一点非常好
对于EclipseRCP应用程序,首先是清单,因为您需要插件透视图和EclipseIDE工具。如果您想将其与maven结合起来,那么tycho可能是一个不错的选择。我完全不同意这一观点,生成清单要比手动维护清单好得多,因为它包含太多重复的信息(例如导入的包)。关于它非常重要的论点是假的,因为应用程序中的
.class
文件也非常重要,而且您不会梦想手工编写这些文件。我并不反对生成清单文件,我只是说您确实需要熟悉它。通过查看清单文件,可以解决或分析stackoverflow中出现的许多问题。我从未见过有人请求字节码。两者的作用确实不同。无论如何,我期待着你的回答。是的。。你必须知道你的清单应该是什么样子。当您生成清单时,您仍然需要检查它是否正常工作,但是您的手动工作要少得多。所以我也支持生成清单。@F