Peter Kriens重返OSGi联盟

上周，OSGi背后的主要推动力之一彼得·克里恩斯（Peter Kriens）在他的博客上宣布他将重返OSGi联盟，在那里他担任了11年的总监，直到2012年初。InfoQ与Peter讨论了他的回归和最新项目jpm4j。 （所表达的观点仅是Peter Kriens的观点，不一定反映OSGi联盟的观点。）

InfoQ：欢迎回到OSGi联盟，彼得。 自您离开以来，您一直在做什么？将来您会做什么？

彼得：我离开的主要原因是我需要回到战es中。 我的计算事业始于七十年代后期，由于运气好，我能够在很小的时候就开发出相当先进的分布式系统。 然后，后来爱立信给了我一个绝佳的机会来领导一些非常大的项目，他们以九十亿美元的高薪在我的应用程序研究实验室中担任了最高职位。 在OSGi成为2001年发送发票的地方之前，这些都是非常实用的形成年份。

但是，经过十多年的规范撰写，我觉得我经常谈论不基于深层实践的理论。 尽管我认为这在我们行业中普遍存在，但是当一项技术不在“我的手指”中时，我会感到非常不满。 由于OSGi企业专家组的重要性日益增加，这种烦恼变得更大了。 我的经验更多来自（半）嵌入式世界，因此许多“最佳”实践使我感到困惑。

离开的第二个原因是关于存储库。 我认为我们今天处理二进制工件的方式存在很多问题。 不要误会我的意思； Maven Central是我们行业不可思议的资产，而不仅仅是Maven用户。 但是，从长远来看，其基于文件/目录的基础模型过于简单。 应用程序的复杂性一直在增长，我认为我们需要用于存储库的更多功能，以便更智能地组织工件。 我试图在联盟中推广这样的OSGi存储库，但不幸的是，它从未受到任何关注。 再次将这个主题与我渴望进入战es的愿望结合起来，听起来像是一个放假的好主意，而我真的很开心！

但是，从今年年初开始，很清楚正确地执行jpm4j会需要更多的人。 我将开始与不同的公司交谈，看他们是否感兴趣，但是我找不到一家愿意对该项目进行充分投资的公司。 现在，业务发展不是我的强项，我确实实现了学习的主要目标，因此总的来说，我实际上很高兴，也很高兴回来。

InfoQ：OSGi的工作量很大，似乎对消费者群来说不成比例。 正在采取什么措施来刺激牵引力？

彼得：恩，我受雇来增加这种采用率。 为了了解我们的策略，让我解释一下我去年的一些经验。

对于jpm4j，我接受了OSGi，并使用Neil Bartlett的Eclipse插件Bndtools进行开发。 必须实际构建一个利用OSGi的，具有实际大小的应用程序非常困难，因为大多数JEE库（以及开放源代码库）在OSGi中显得笨拙且笨拙。 因为我不想妥协（毕竟我正在学习），所以我不得不开发许多“本机” OSGi解决方案。 我为诸如安全性，排队，配置，批处理作业，mongo，浏览器集成等主题开发了捆绑软件。事实证明，这些组件比JEE或开放源代码的组件要简单得多。 并不是说我太聪明了，我可以用几个星期的工作来替换这些有时相当大的库，不幸的是不能。 我之所以能够摆脱它，是因为OSGi提供了一组大多数库以专有方式复制的原语。 通过标准化生命周期，依赖关系和配置原语，组件往往具有开箱即用的协同作用。 如果您使用OSGi，您会发现您经常不得不编写非常少的代码，因为环境处理了很多平凡，容易出错的细节。 在非OSGi世界中，由于没有用于服务发现，生命周期和配置的此类标准，因此您必须经常发现自己在重复自己以及编写粘合代码。

现在，将其与Bndtools结合使用。 我承认没有尝试过市场上的所有IDE，但是我很害怕我的OSGi框架保持运行，而捆绑包每天更新数百次。 按下Ctrl-S，切换到浏览器，刷新它，然后查看结果，真是太好了。 它的时间与Ruby on Rails的编辑-调试周期一样短，但现在具有Java，Eclipse和OSGi的所有强大功能。 现在，您可以吃蛋糕（快速的编辑-调试周期），也可以吃（重构，快速帮助，类型安全，导航，强大的模块化，µservice等）。

因此，我实际上是深深地爱上了OSGi ... ...但是，这一次，我对OSGi在企业中的优势及其缺点有了更好的了解。 我一直说OSGi是一个梦幻般的混凝土基础，可以为最高的摩天大楼做好准备，但是即使建立一个漂亮的小排屋，也几乎没有支持。 结果是许多人必须自己整合各个部分。 所需要的是一个OSGi应用程序框架，该框架可满足最大的一组开发人员Web应用程序开发人员的共同需求。 我坚信我们可以为OSGi构建类似这样的东西，而无需付出太多努力。 几乎所有零件都已经在那里； 缺少的是一种将所有这些部分组合成一个完整的应用程序的方法。

因此，我建议对OSGi联盟进行此类评估。 OSGi联盟总裁IBM的Dan Bandera提出了一项建议，并在董事会中进行了讨论。 当我被告知他们希望我立即开始时，我感到很惊讶！ 由于我仍然想对jpm4j做一些工作，因此我们决定将时间分配到联盟和jpm4j的工作之间。

InfoQ：您能告诉我们有关jpm4j的信息吗？

彼得：几年前，我意识到随着时间的推移，公共存储库将永远增长，因为您永远都无法删除任何修订。 删除修订可能会破坏一些构建！ 鲜为人知的是，当您使用版本范围或功能强大的OSGi功能/需求模型时，向存储库添加修订也会破坏构建。 具有版本范围的构建现在可以工作，明天就可以失败，因为存储库具有可用的较新版本。 也就是说，存储库的内容是构建依赖项中的头等公民。 Sonatype建议人们不要使用Maven版本范围的主要原因是，这通常不是很好理解的存储库方面。

许多年前，我已经很清楚仓库需要像源代码控制一样进行版本控制的事实。 因此，在OSGi联盟内部，我们始终使用源代码管理系统来管理二进制依赖关系。 我认为应该有机会提供基于云的存储库服务，即类似于Github的二进制文件。

但是，要对存储库进行版本控制，首先需要具有所有可能工件的目录。 在与Karl Pauls和Richard S. Hall（OSGi的提交者和Manning的OSGi in Action的合著者）进行了为期一周的讨论之后，我得出的结论是，我需要一个公共社区站点，其中包含所有可用工件的目录。 然后，该目录可以成为我的版本库的基础。 但是，拥有这样的目录也使我能够解决巨大的挫败感，这就是我所说的Java的“最后一英里”。 几乎所有动态语言都可以通过某种方式将其应用程序安装在不同的操作系统上。 NPM ， Gem ， CPAN等。虽然Java可以说是有史以来最可移植的语言，并且具有可移植二进制文件的巨大优势，但是开发人员必须跳过太多的麻烦才能安装应用程序。 因此，jpm4j具有jpm命令，这使得在命令行上或作为服务本地安装应用程序变得很简单。 Jpm知道如何在Windows，Linux和MacOS上处理应用程序，并将这些应用程序安装在适当的位置。

尽管随着时间的流逝，此功能有些落后，但它使jpm4j有了它的名字：“ Just another Package Manager for Java”。 也就是说，它还没有完成，还有很多工作要做。 如果正确的话，整个项目相当可观​​。 如前所述，我正在与一家愿意为其提供良好住房并为进一步发展提供资金的公司交谈。

InfoQ：听起来在纸上很有趣，但是难道不是鸡和蛋的问题，用大量有用的捆绑包来引导仓库吗？

彼得：嗯，当时我的主要目标不是OSGi。 是的，我知道这听起来很奇怪。 Jpm4j是一个Maven存储库，因为它是迄今为止最受欢迎的存储库模型。 因此，我想将这些版本存储库提供给Maven世界。 就是说，由于我对OSGi的投入仍然非常坚定（比我当时意识到的还要多），我确保OSGi是这个世界上的头等公民。

从Maven Central中的所有工件开始很简单。 jpm4j核心主要是JAR的目录，因此我为Maven Central编写了一个扫描器，并自动导入了它们的所有工件。 Jpm4j扫描所有JAR，并在检测到OSGi捆绑软件时将其分类。 Jpm4j可以提取Maven元数据和OSGi元数据，并具有用于其他元数据的插件模型。 jpm4j当前有40万多个修订版。

但是，尽管jpm4j以Maven为中心，但它与任何存储库格式无关。 我还使在Github上创建二进制存储库变得非常容易，您只需要在Github上提供post钩子，然后jpm4j将扫描该存储库并更新其目录。 詹金斯（Jenkins）构建可以做类似的勾子。 我计划还扫描所有Eclipse捆绑软件，并包含许多公司存储库。

因此，我试图使人们很容易地向世界其他地方开放他们的捆绑包。 我想我在那里成功了。 阈值实际上很低。

InfoQ：消费者呢，他们需要消费到捆绑软件才能迁移到OSGi吗？ 还是打算用于刚刚开始的项目？

彼得：好吧，我也没有。 OSGi是一项重大的投资，因为它不像某些库那样只能在类路径上拍打并获得一些出色的新功能。 OSGi很小，因为大多数工作是由您（用户）完成的。 Parnas的开创性模块化论文全都涉及如何将问题分解为模块，以使模块之间的耦合最小化，凝聚力最大化。 当我们试图传播面向对象的范例时，面向对象社区践踏了我们在70年代所学的简单课程。 OSGi只是提供执行这些模块的原语的结构。

OSGi的巨大好处是可以用更少的代码来完成更多工作，并且更容易维护。 但是，正确完成后，这几乎会影响开发过程的任何部分。 尽管有明确的迁移路径，但如果没有更改意愿，我不会尝试OSGi。 这与减轻体重非常相似，临时饮食很少能长期起作用； 如果您想变得苗条和保持苗条，就需要改变自己的生活方式。 因此，如果您想控制膨胀的代码库的成本，只有一种快速解决方法：等到计算机变得更快为止。 既然摩尔定律在经典顺序程序中已用尽，那么快速解决方案将变得越来越困难。

也就是说，从OSGi开始的门槛太高了。 由于这个陡峭的门槛，太多的开发人员遭受了漫长的学习曲线。 显然，我知道那里的应用程序服务器框架，但这不是我的意思。 这些框架没有利用OSGi的真正优势。 在寻求JEE兼容性的过程中，它们倾向于结合两种环境的缺点。 OSGi的最酷的功能是服务模型，但是这些环境都不支持它。 我希望展示如何通过我的新OSGi工作来完成此工作。

InfoQ：OSGi需要高度的专业知识，也许该专业知识正是缺少的一环，这使得软件工程比其他工程专业更加模糊。 但是，我们怎么能期望一直采取一种方法的团队改变路线，获得新的学科成就，并开始考虑模块而不是行业中普遍存在的临时体系结构来思考呢？

彼得：就像我之前说的，OSGi是一种生活方式，而不仅仅是饮食。

现在，您提出的有趣一点是，我们如何通过我们的工作方式脱身（这是一个5,000亿美元的产业？）。 有很多原因，但我的拙见认为根本原因是我们不承担责任。 如果亚马逊违反其服务水平协议（SLA），他们只会退款给您。 如果因为薪资计划崩溃而没有给员工发薪，那将是艰难的。 如果量化指标炸毁了金融体系，那么，社会就会予以救助。 每个30岁以上的企业开发人员都曾从事过失败的项目，但我不知道有人因此而失业。 相反，建一座桥，当它倒塌时，尝试将其耸耸肩； 那永远不会飞。

在嵌入式世界中，您会看到制作软件时要更加谨慎，因为它们通常对软件负责。 例如，汽车公司知道，任何方面的失败都会导致非常昂贵的诉讼。 但是，在企业软件世界中，实际上没有这种反馈回路。 结果就是一切顺利。 我希望我们是唯一拥有摇滚明星，流行趋势和时尚的工程学科。 责任的缺乏在我们的行业中造成了各种错误的诱因。

它永远不会使我感到惊奇，开发人员将如何花费大量的时间，却完全拒绝花费甚至一角钱。 责任将使非开发人员深入参与开发过程。 对于非开发人员，时间和金钱之间的权衡更加透明。 我相信这将很快推动OSGi的发展。

在此之前，OSGi最重要的事情是通过基层努力来推动采用。 这显然是我为OSGi联盟工作的目标之一。 通过在最常见的情况下使开始使用OSGi更加容易，我们希望增加对OSGi的了解并展示服务模型的好处。 许多开发人员都喜欢OSGi的体系结构，我认为正是入门部分使他们脱颖而出。

InfoQ：您会在OSGi联盟中管理其他任何角色吗？

彼得：尽管这次我不会写规范，但是我将参加一些技术专家组，当然我会再次访问会议电路。 我计划提出一些规范，以使Web应用程序更易于构建。 我也参加董事会会议。 对于其他50％的用户，我打算进一步推广jpm4j，因为它显然尚未完成。

InfoQ：社区可以做些什么？

彼得：我很想获得有关OSGi降低门槛的想法。 我也对任何想讨论jpm4j的人都感兴趣。 我打算在这两项工作中尽可能让社区。

InfoQ：一个个人问题，我已经看到您在各种会议上多次演讲，您的演讲总是和您所展示的技术一样令人叹为观止。 您是如何做到的，您是否有针对演示者的提示？ 您如何定位或制作此类即时图形，将它们绑在一个时髦的bblb上，并以您独特的风格来呈现出有意义的展示？

彼得：哇，谢谢。 实际上，每次上台时，我在这方面总是感觉不足，因此很难回答这个相当意外的问题。

我只能为自己说的是我非常注重视觉。 主要原因是我可以盯着一个XML文档花几个小时而无法得到它。 但是给我看一个好的图表，这似乎很明显。 只需查看OSGi规范即可； 很少有规格有很多精心制作的插图。 主要原因是要确保我确实“懂了”。 我有很多朋友不看这些图，并且能够从XML文档中获得相同的信息，并且它们总是给我留下深刻的印象。 我的大脑需要图形，我想这会影响我的演示。

翻译自: https://www.infoq.com/articles/Peter-Kriens-Returns-To-OSGi-Alliance/?topicPageSponsorship=c1246725-b0a7-43a6-9ef9-68102c8d48e1