我是芭蕾舞女演员的新手。我将平台库作为可执行 jar 导入，这是使用 jclouds 的 openstack swift api 在 java 中的互操作方法调用。
JCLOUDS 存在一个已知问题，即在Spring Boot 应用程序中使用 Rackspace 时，由于高于 2.5 的 gson 版本问题与 jclouds Apache jclouds java.lang.NoSuchMethodError不兼容而无法构建 。
尝试从我的 bal 文件中执行这个 inter op 方法调用时，我遇到了同样的错误，该文件是在芭蕾舞演员构建期间构建的。检查芭蕾舞女演员在项目构建期间创建的 jar 后，发现该 jar 是使用一组预构建的 gson 2.7 依赖项创建的。
有什么办法可以改变这种依赖关系，我也不太清楚芭蕾舞女演员如何在 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 运行时的依赖项
每个 Ballerina 可执行程序都包含 Ballerina 运行时 - JVM 上执行任何 Ballerina 程序所需的最低层。运行时包含 Ballerina 值、类型、lang lib中的 Ballerina 模块和运行时类型检查器逻辑的 Java 实现。这一层对于在 JVM 之上实施 Ballerina 语言语义至关重要。
目前，Ballerina 运行时依赖于许多第三方 Java 库。GSON 就是这样一个我们计划很快删除的库。您可以从上述问题中获得更多详细信息。
Ballerina 模块的依赖项
每个 Ballerina 模块，无论它属于标准库还是您从Ballerina central 中提取的，都可能依赖于一个或多个第三方 Java 库。Ballerina 模块作者在他们开发 Ballerina 模块的项目的 Ballerina.toml 中列出了这些依赖项。这里有些例子。
在我研究这个答案时，我意识到需要一个调试工具来发出第三方库的详细信息。如果此工具可以集成到ballerina命令行工具中，那就太好了。这是我为跟踪此问题而创建的问题。
https://github.com/ballerina-platform/ballerina-lang/issues/20116