我是芭蕾舞 Actor 的新手。 我将平台库作为可执行 jar 导入，这是使用 jclouds 使用 openstack swift api 在 java 中进行的互操作方法调用。
JCLOUDS 存在一个已知问题，由于高于 2.5 的 gson 版本问题与 jclouds 不兼容，因此无法构建 Apache jclouds java.lang.NoSuchMethodError when using Rackspace in a Spring Boot application .
当我尝试从在 ballerina 构建期间构建的 bal 文件执行此互操作方法调用时，我遇到了相同的错误。检查 ballerina 在项目构建期间创建的 jar 后，发现该 jar 是使用 gson 2.7 的一组预构建依赖项创建的。
有什么方法可以改变这种依赖关系，我也不太清楚 ballerina 在 bal 文件的构建阶段如何打包所有这些 jar。
这将有助于详细了解调用 ballerina build 时幕后发生的情况。
最佳答案
以下 GitHub 问题解释了为什么我们必须将 com.google:gson:2.7 与任何 Ballerina 可执行 jar 一起打包。
https://github.com/ballerina-platform/ballerina-lang/issues/17878
让我尝试解释一下为什么 Ballerina 编译器将一些第三方 jar 与为 Ballerina 程序创建的可执行 jar 一起打包。我们可以将这些第三方 jar 分为两大类。
- Ballerina 运行时的 Jar 依赖项
- 您在程序中导入的每个 Ballerina 模块的 Jar 依赖项。
Ballerina 运行时的依赖关系
每个 Ballerina 可执行程序都包含 Ballerina 运行时 - 执行任何 Ballerina 程序所需的 JVM 之上的最低层。运行时包含 lang lib 中 Ballerina 值、类型、Ballerina 模块的 Java 实现，以及运行时类型检查器逻辑。该层对于在 JVM 之上强制执行 Ballerina 语言语义至关重要。
目前，Ballerina 运行时依赖于许多第三方 Java 库。 GSON 就是这样一个库，我们计划很快将其删除。您可以从上述问题中了解更多详细信息。
Ballerina 模块的依赖关系
每个 Ballerina 模块，是否属于 standard library或者您是否从 Ballerina central 中提取它，可能依赖于一个或多个第三方 Java 库。 Ballerina 模块作者在开发 Ballerina 模块的项目的 Ballerina.toml 中列出了这些依赖项。这里有些例子。
当我在研究这个答案时，我意识到需要一个能够发出第三方库详细信息的调试工具。如果这个工具可以集成到 Ballerina 命令行工具中，那就太好了。这是我为跟踪此问题而创建的问题。
https://github.com/ballerina-platform/ballerina-lang/issues/20116
关于jclouds - 新手/芭蕾舞 Actor 在运行构建时出现 gson 问题，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/59106362/