Liferay 版本和正确的依赖关系答案

【问题标题】：Liferay versions and correct dependenciesLiferay 版本和正确的依赖关系
【发布时间】：2019-12-29 06:04:00
【问题描述】：

我对 Liferay、Maven 和 Java 比较陌生，所以这可能是关于依赖关系的一般性问题。我正在维护一个已从 6.2 迁移到 7.1 的 Liferay portlet，并且有许多带有版本号的 Liferay maven 依赖项（例如 com.liferay.portal.kernel）。

如何知道他们使用的产品版本要使用这些依赖项的哪些版本？

这是一种典型的情况，即使产品版本落后于次要版本，也应该始终尝试使用最新版本的依赖项？

【问题讨论】：

标签： maven liferay liferay-7 liferay-7.1

【解决方案1】：

要确保再次编译目标环境中的 JAR 版本，最简单的方法可能是使用相应的 BOM（材料清单）。

例如，您可以查看code sample's POM for Liferay Portal 7.2。请注意 dependencyManagement 指示要使用的 BOM：

    <dependencyManagement>
        <dependencies>
            <dependency>
                <groupId>com.liferay.portal</groupId>
                <artifactId>release.portal.bom</artifactId>
                <version>${portal.version}</version>
                <type>pom</type>
                <scope>import</scope>
            </dependency>
        </dependencies>
    </dependencyManagement>

然后注意com.liferay.portal.kernel JAR 的实际依赖项如何没有指定版本。

        <dependency>
            <groupId>com.liferay.portal</groupId>
            <artifactId>com.liferay.portal.kernel</artifactId>
        </dependency>

JAR 版本将从 BOM 中获取，以确保它与 Liferay Portal 的给定版本相匹配。

为了比较，这里是exact same POM but for Liferay Portal 7.1。如您所见，唯一的区别是 portal.version 属性。

【讨论】：

这样比较简单，但不适合某些场景。一件事是它可用于 7.1 GA2+，其中不包括许多 7.x 版本和/我们的特定发行版。此外，您可能会对发布 7.1 GA2 和 GA3 以及其他版本的 sing jar 感兴趣，在这种情况下，您将使用范围或使用仅编译依赖项绕过依赖项版本控制（风险自负）。在那些情况下，你不能服从这个依赖管理器。例如，Liferay 有几个依赖于内核 2.0 的 JAR（现在隐藏在源代码中）..
取决于您的公司，这实际上是可以理解的，您可能有一个项目将 jar 提供给其他几个项目，从 GA1 到 GAX 甚至从 7.0 到 7.2。
这里有一个有用的链接：mvnrepository.com/artifact/com.liferay.portal/…

【解决方案2】：

如何知道要使用这些依赖项的哪个版本他们正在使用的产品版本？

有几种方法可以知道您正在使用哪些依赖项版本。最简单的方法是打开您的捆绑包的 jar 文件并查看清单文件。

当然，打开清单是相当乏味的。您可以使用系统的 Gogo shell 来获取有关正在运行的系统上的捆绑包的信息。

或者你可以寻找对 git 的依赖。使用与您的系统相对应的 Liferay 标签，并从您在 bnd 文件中看到的版本的次要部分中减去 1。

最后，日志可以帮助您判断何时缺少依赖项或存在版本号不匹配的包版本。

就个人而言，我会说 Gogo shell 和 App manager 选项是最简单的方法.. 但有时你已经在 git 上..

这是一个应该始终尝试使用最新版本的依赖项，即使是产品的版本是次要版本吗？

不，这对你来说不是一件好事。尽管版本方案的次要部分通常表明事情不太可能发生故障，但确实如此。如果您使用在次要版本中添加的方法，则在您正在运行的系统上，该方法将不可用，并且调试可能会令人困惑，因为您会清楚地看到您的 IDE 甚至会自动完成不存在的东西。

此外，使用最新版本编译模块并没有真正的优势，因为系统上运行的模块没有更新，将运行的是您的产品附带的模块（如果您没有更改它，甚至在你的 on 模块中安装或嵌入它......但如果你对你的包进行了调整，那么你可以跟踪......）。

您可以使用 3.1.+ 之类的版本范围来构建您的模块，假设使用该依赖项编译的模块将适用于正在运行的系统中的所有 dot 版本。如果已知依赖项与其自身的旧版本兼容，您可以使用旧版本进行构建，而系统将运行新版本。 Liferay 一直在他们自己的代码中执行此操作（有时被默认一词隐藏）。当然，如果您这样做，您将无法享受最新的功能和 IDE 提供的自动完成和验证功能。

您还需要注意，在基于 OSGi 的系统中，同一库的多个版本是可能的。有时，只有一个运行（单例），但有时运行时会有几个可用...所以，您可以选择最新的可用...

因此，简而言之：如果您的系统无法运行，请不要使用最新版本来构建它。也许范围有效，但您需要根据其版本控制方案检查该依赖项是否真的关心在该范围内兼容。

有用的链接：

【讨论】：