由于“类型不兼容”，mvn 安装失败

发布于 2024-12-20 06:55:03 字数 1400 浏览 4 评论 0原文

收到以下错误

我从“mvn clean install” [ERROR] /private/tmp/framework/src/main/java/org/jboss/narayana/txframework/api/annotation/transaction/WSBA.java ： [21,65] 不兼容的类型找到：org.jboss.narayana.txframework.api.configuration.transaction.CompletionType 必需：org.jboss.narayana.txframework.api.configuration.transaction.CompletionType [错误] /private/tmp/framework/src/main/java/org/jboss/narayana/txframework/api/annotation/service/ServiceRequest.java:[32,56] 不兼容的类型找到：org.jboss.narayana.txframework.api.configuration.service.RequestType 必需：org.jboss.narayana.txframework.api.configuration.service.RequestType [INFO] 2 个错误

我假设这是一个依赖问题，并且构建路径中的某个地方还有另一个 CompletionType 实例。我已经检查过情况并非如此，并且还尝试使用空的 ~/.m2/repository。

我尝试重命名有问题的包的包，但这并不能解决问题。我只是在两行中使用新的包名称时遇到相同的错误。

我在 pom.xml 中的依赖项不应包含包含这些类的库。

我尝试在另一个开发人员的计算机上重现此问题，但问题并未发生。

我在两台计算机上看到此问题。这些计算机的很多环境都已同步，因此问题也已同步，我对此并不感到惊讶。然而，在我的办公室计算机上，我可以在 Intellij 中成功执行“mvn install”，但不能在命令行上执行。在我的家用计算机上，我在命令行和 IntelliJ 中都遇到了这个问题。

我已经尝试用 Google 搜索这个问题，但是一旦我从构建中删除了特定于我的项目的文本，我就没有足够具体的内容可供搜索。

pom.xml 可以在这里找到：

http: //anonsvn.jboss.org/repos/labs/labs/jbosstm/trunk/txframework/framework/pom.xml

是的，我我知道这是一个 JBoss 包，其中出现了问题。我为 JBoss 工作，这是我的代码，所以我无法让他们修复它；-)

谢谢。

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

朮生 2024-12-27 06:55:03

这是由该版本的 Oracle JDK 中编译器的注释处理中的 bug 引起的：

java version "1.6.0_27" Java(TM) SE 运行时环境（版本 1.6.0_27-b07） Java HotSpot(TM) 64 位服务器 VM（版本 20.2-b06，混合模式）

它也出现在等效的 mac 版本中，在发布时是最新版本。

我通过切换到此版本的 OpenJDK 解决了该问题：

java version "1.6.0_22" OpenJDK 运行时环境 (IcedTea6 1.10.4) (fedora-60.1.10.4.fc15-x86_64) OpenJDK 64 位服务器虚拟机（版本 20.0-b11，混合模式）

如果您无法切换 JDK（例如，如果您有 Mac），可以采取解决方法。

更多详细信息可以在我用来跟踪此问题的错误报告中找到：

https:// issues.jboss.org/browse/JBTM-997

回复收藏 0 原文

烟雨凡馨 2024-12-27 06:55:03

编辑：我重组了这个答案，因为它的主要目的是提供一个解决方案来发现问题而不是解决问题。这些元素按照我在评论或此处发布的顺序添加。

这不是一个常规的依赖问题，因为如果您更改类的名称，这个问题就会消失。
可能与java版本有关。尝试明确设置源和目标。
这可能是您的依赖结构中错误的 jar，请尝试以下操作：
将其添加到您的 pom 中：

    <plugins>
        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-dependency-plugin</artifactId>
            <configuration>
                <outputDirectory>
                    ${project.build.directory}
                </outputDirectory>
            </configuration>
            <executions>
                <execution>
                    <phase>initialize</phase>
                    <configuration>
                        <version>4.0.0</version>
                    </configuration>
                    <goals>
                        <goal>copy-dependencies</goal>
                    </goals>
                </execution>
            </executions>
        </plugin>
    </plugins>

调用 clean install，然后在 shell 上尝试此命令（在项目的基本路径中，而不是 dist 目录中。）：

find . -name "*jar" -exec jar -tvf {} \; |grep RequestType

这样您就可以看到类路径上有多少个 RequestType 的表示形式，也许您会看到在哪里错误的来自。

现在可能存在正确的类版本，但引发问题的类 (ServiceRequest.java) 编译时使用了错误的版本。将它们放在同一个类路径中，然后重试。
您的磁盘上是否有该类的旧版本？尝试删除它（如果您仍然需要它，可以将其移动到便携式设备上）。
手动删除类路径中的每个二进制文件。不要依赖“mvn clean”来工作。
打印出maven正在使用的类路径（谷歌会告诉你如何做）。检查是否有任何您没有预料到的内容。
（模糊）通过使用 UTF 的更模糊的功能，可以两次创建完全相同的目录。如果你的路径包含非 ASCII 字符并且你的一台机器是 Mac（真的，不是开玩笑。对于德语能力者：http://www.danisch.de/blog/2011/11/18/wer-unicode-und-utf-erfunden-hat-gehort-erschlagen/）。
您检查过环境变量设置是否正确吗？仔细检查它们。
调用：
mvn 干净
mvn编译

然后查看有多少个有问题的类的实例。

Edit: I restructured this answer, because its primary purpose is to provide a solution to find the problem rather than solving it. The elements are added in the order I posted them in the comments or in here.

It is not a regular dependency problem, because that would go away if you change the name of your classes.
It could be related to the java version. Try setting source and target explicitly.
It can be a jar thats wrongly in your dependency structure, try this:
add this to your pom:

    <plugins>
        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-dependency-plugin</artifactId>
            <configuration>
                <outputDirectory>
                    ${project.build.directory}
                </outputDirectory>
            </configuration>
            <executions>
                <execution>
                    <phase>initialize</phase>
                    <configuration>
                        <version>4.0.0</version>
                    </configuration>
                    <goals>
                        <goal>copy-dependencies</goal>
                    </goals>
                </execution>
            </executions>
        </plugin>
    </plugins>

call clean install and then try this command on your shell (in the base path of the project, NOT the dist dir.):

find . -name "*jar" -exec jar -tvf {} \; |grep RequestType

That way you see how many representations of RequestType are on your classpath maybe you see where the wrong one comes from.

Its possible that the right version of your class exists now, but that the class that originating the problem (ServiceRequest.java) compiles against the wrong one. Put them both in the same classpath, then try again.
Have you somewhere on your disk an old version of the class? Try removing it (by moving it on a portable device if you still need it).
Delete every binary in your classpath manually. Don't rely on 'mvn clean' to work.
Print out the classpath (google will tell you how) maven is using. Check that there is nothing on that you did not expect.
(Obscure) Its possible to create the very same directory twice by using the more obscure features of UTF. That would happen if your paths contain a non ASCII Character and one of your machines is a Mac (really, no joke. For german capable: http://www.danisch.de/blog/2011/11/18/wer-unicode-und-utf-erfunden-hat-gehort-erschlagen/).
Have you checked that your environment variables are set correctly? Double check them.
call:
mvn clean
mvn compile

then see how many instances of the offending classes you have.

回复收藏 0 原文