来自 Adobe 的用户体验专家 AEM 之 第三方包的部署

分享一下我老师大神的人工智能教程。零基础！通俗易懂！风趣幽默！还带黄段子！希望你也加入到我们人工智能的队伍中来！https://blog.csdn.net/jiangjunshow

                CQ 的构建基于 Apache Sling，而 Apache Sling 则是构建于一个 OSGi 容器之上 (确切来讲是 Apache Felix)。
OSGi 容器的行为 (就类文件的加载方式以及在 classpath 中可用) 和大多数 Java 开发者所习惯那样略有不同。
要确保类能够在 OSGi 容器中可用，需要使用一个特定的方式对它们进行打 jar 包，包括向标准的 MANIFEST.MF 文件中添加额外的元数据。这样带来的一个问题就是由其他开发者所创建的库对于 OSGi 来讲这一附加信息是缺失的，因此他们的 jar 文件也就无法部署在 CQ 中。
本文将详细介绍如何将非 OSGi 库简单可靠地暴露在 CQ 中。关于创建并部署 OSGi bundle 到 CQ 的详细步骤请参考博客《 构建并部署 OSGi bundle》。

一个很 low 的解决方案

对于这个问题的一个解决方案可能是拿到第三方 jar 文件，解压，向 manifest 文件中添加额外的信息，重新打包并部署到 CQ。这样做主要的问题至少有三个：

1. 如果该第三方 jar 文件被签过名，这么修改的结果将导致该签名失效，而任何相关的校验工具会因此产生警告甚至失败。总和检查也会有类似的问题。
2. 第三方 jar 有新版更新时，这种手工 "升级" 过程需要进行再次调整。
3. 在团队协作环境中，将修改后的 jar 提供给每个人都是会有问题的。可能它会被推送到团队库里并覆盖掉了那个没有修改的 jar - 大部分的库管理工具不会喜欢你这么干 (原因见第 1 点)。或者，也许每个团队成员能够把修改后的 jar 推送到自己本地库里，但是在他们每次进行构建的时候 Maven 可能要报告问题了 (原因还是去见第 1 点)。

最关键的问题是手工修改 artifact 着实是一个糟糕的主意，只会带来麻烦，经常还会是那种非常难以调试的麻烦。

推荐方案

理想方案是创建你自己的封装有一个或多个这种非 OSGi jar 的 OSGi bundle。这么干有以下好处：

1. 可以使用 Apache Maven 去自动化执行整个过程，因此这是可靠且可重复的。
2. 原始的第三方 jar 没有被修改。
3. 当第三方有一个新版本的 jar 时，只需要调整 POM 中的依赖。然后简单地发布该 bundle 的一个新版。
4. 由于该 bundle 是一个对的 Maven artifact，它可以很方便地进行团队成员内部共享，而不会有签名以及总和检查之类的问题。

废话不多说，先创建一个新的 Maven 项目。在 POM 文件中将 packaging 设置为 bundle 并把 Apache Felix bundle 插件 include 进来：

<?xml version="1.0" encoding="UTF-8"?><project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd"> <modelVersion>