apache karaf 怎么上传不是osgi的jar包

打开eclipse，码运点新建-》其他，选择如图所示选择你要转换的jar包。填入项目名，目标平台选择，OSGi框架-》标准。最重要的一步来了，查看源jar包的MANIFEST.MF配置，查看是否Import-Package这一项。如果有这一项，把这一项全部复制到的所转换的bundle的MANIFEST.MF配置文塌答件里。选中工程，右键-》导出，选择你要团模慧导出的bundle和生成bundle的目录。

ONOS和ODL分别由运营商和厂商主导，所代表的利益不同，也就分别选择了两种不同的SDN演进方式。前者更贴近于SDN诞生之初时狭义的SDN概念，即通过OpenFlow将控制平面和转发平面完全分离，网络设备只是进行转发的黑盒子，通过Controller完成一切计算。ONOS所选择的理念与运营商自己的利益息息相关，只有将控制能力拿到自己手里，才能在整条产业链上逐步摆脱设备厂商的控制。通过使用更为廉价的转发设备替代原有的厂商设备，一方面在眼下增加自己与设备厂商的议价砝码，另一方面长远看能大大降低网络的建设和维护成本。相比较而言，ODL则采取了更为平缓的SDN演进方式，从理念上更为贴近广义的SDN，即不局限于OpenFlow协议，不局限于完全将控制平面从转发设备上剥离，通过已有的网络协议将部分的控制逻辑放到Controller上。这样的理念使广义的SDN技术的落地更容易成为现实，一方面通过保护运营商、企业等设备厂商客户的既有投资，使客户可以真正感受到SDN技术的实际效果。另一方面，通过在现有设备上扩展已有的网络协议，厂商能够使自己的设备在不用伤筋动骨就能保有竞争力，避免自己在SDN的革命中被迅速甩下。从技术上讲，SDN Controller实际上解决的是南向与设备的通信问题和北向向APP提供的资源问题，网芹腔络运营者根据自己网络的业务特点提出的控制逻辑则需要缓枝开发APP来实现。从南向接口上看，ONOS目前成熟的南向接口只有OpenFlow，而ODL Helium版则支持OpenFlow、OVS-DB、MP-BGP、PCEP、NETCONF/YANG等极为丰富的南向接口以连接不同类型的设备。从北向接口上看，ODL采用的MD-SAL使得设备资源可以通过YANG model直接转换为RESTConf API，而ONOS还在某种程度上停留在ODL最初版本使用的AD-SAL架构，API需要在plugin设计时单独考量。当然除此之外，Controller的性能与Scale out也是嫌哪衫必须面对的问题。对此，ONOS确实抓住了ODL尚未解决的问题，从一开始就从这两方面抢占先机，拨人眼球。不过从二者实现上都采用了JAVA的Karaf框架来看，性能与Scale out问题在根本上也不会存在先天的差别，面对海量计算采用Cluster会是最终的解决方法，而实际上两个控制器都提供了相应的Cluster部署方案。唯一的问题可能是ODL还需要应对多种南向接口带来的额外消耗，但ODL提供的是南向接口的可选能力，实际部署上也很少会出现多种协议共存的情况。但值得一提的是，尽管ONOS主推OpenFlow，但在其Wiki上也列出了合作厂商正在ONOS上开发PCEP、TL1等南向接口，所以也许不久之后我们就会看到ONOS也开始支持各种各样的南向接口了

文件损坏。kettlekaraf是一款国外开源的ETL工具，猛档纯java编写，可以在Windows、Linux、Unix上运行，数据抽取高效稳定，但其无法加载受损铅知竖的stringutils文件，如果存在受损的stringutils文件，软件会第一时间槐大d出警示框，并不予加载。

---