我有一个项目，它被设置为编译我的resources目录中指定的protobufs。为此，我使用xolstice插件，配置如下：
<plugin>
<groupId>org.xolstice.maven.plugins</groupId>
<artifactId>protobuf-maven-plugin</artifactId>
<executions>
<execution>
<goals>
<goal>compile</goal>
<goal>compile-custom</goal>
</goals>
</execution>
</executions>
<configuration>
<protocArtifact>com.google.protobuf:protoc:${protobuf.version}:exe:${os.detected.classifier}</protocArtifact>
<pluginId>grpc-java</pluginId>
<pluginArtifact>io.grpc:protoc-gen-grpc-java:${grpc.version}:exe:${os.detected.classifier}</pluginArtifact>
</configuration>
</plugin>
这大致是这里描述的配置。有问题的原型包括一些对象模型以及我注册使用的GRPC服务。
.jar很容易打包，其中有一个maven-jar-plugin，我从我们的公共根pom继承而来。其配置为：
<plugin>
<artifactId>maven-jar-plugin</artifactId>
<version>3.2.0</version>
<configuration>
<archive>
<manifest>
<addDefaultImplementationEntries>true</addDefaultImplementationEntries>
<addDefaultSpecificationEntries>true</addDefaultSpecificationEntries>
</manifest>
</archive>
</configuration>
</plugin>
当我在IntelliJ中运行我的项目时，一切似乎都很好——我可以观察到所需的原型是正确生成的，我没有任何问题。然而，当我使用java -jar target/service.jar运行.jar时，我会遇到以下问题：
[Byte Buddy] ERROR com.artistchooser2.handlers.ChooseArtistsHandler [jdk.internal.loader.ClassLoaders$AppClassLoader@5c29bfd, unnamed module @776b83cc, Thread[main,5,main], loaded=false]
java.lang.IllegalStateException: Cannot resolve type description for com.artistChooser2.v1.ChooseArtistsServiceGrpc$ChooseArtistsServiceImplBase
at net.bytebuddy.pool.TypePool$Resolution$Illegal.resolve(TypePool.java:161)
at net.bytebuddy.pool.TypePool$Default$WithLazyResolution$LazyTypeDescription.delegate(TypePool.java:1038)
应该由协议编译步骤生成的类似乎找不到。然而，有趣的是，我可以很容易地通过运行jar -tvf target/service.jar |grep 'ChooseArtistsServiceGrpc$ChooseArtistsServiceImplBase'来确认这一点。如果我运行它，我可以观察到类实际上是可用的，并且与.jar一起正确打包。我还可以通过仔细阅读.jar中的所有内容，在IntelliJ中很容易地验证这一点。
我注意到这个问题是因为我正在设置一个测试，在Docker映像中运行我的服务，并验证它是否正确启动，就像在生产中一样。然而，有趣的是，尽管我在本地无法成功运行mvn verify，但我的构建服务器(我已经确认正在运行mvn verify(运行到完全没有问题。
我已经检查了所有常见的可疑因素——它与构建服务器上使用的maven构建配置文件无关，maven版本在构建服务器和本地都是相同的，我甚至尝试清除.m2/repository，以防出现可疑情况。
所以我想我的问题是，是否有人有进一步的线索？我是否应该研究其他一些东西，某种环境变量，或者其他任何可能在本地而不是在构建服务器上导致上述异常的东西？
所以我仍然不完全确定这个问题到底是如何表现的——在我的.proto规范中，我有：
option java_package = "com.artistChooser2.v1";
有趣的是，在我的本地机器上，当我在打包的.jar中发现编译后的protos时，它们出现在com.artistchooser2.v1下。注意小写字母"c"。但我正在运行的测试仍然是在上面的"C"包中查找。
出于某种原因，在构建服务器上，它们实际上是在正确的位置进行编译的，但不是在我的本地jar上。我运行的是Mac，而构建服务器是Linux。好奇它是否与环境有关。
无论哪种方式，解决方案都是将包名称更改为我的机器所期望的名称，即较低的"c"，这可能是一个更好的包名称。