当前位置: 首页 > 工具软件 > fast dex > 使用案例 >

.java .class .dex_java.lang.IllegalStateException:Dex存档:仅为.CLASS文件设置.DEX扩展名 (java.lang.IllegalStateE...

韶兴德
2023-12-01

Configuring for multidexing did not solve this issue for me.

However I did come up with a resolution...of sorts. Basically it involved creating a pull request for a second branch on the same commit as the build that was failing. The build for this pull request succeeded, and then Bitbucket thought that the original pull request was ok and allowed us to merge, even though we had made no changes on that branch. There is some unexplained weirdness there but the technique worked.

Here's how I did it:

Assume that the branch that is failing is called bad-branch.

I created a new branch called bad-branch-copy on the commit that was common between bad-branch and develop. Then I merged bad-branch into bad-branch-copy. The end result of this was a fast forward such that bad-branch-copy ended up on the same commit as bad-branch. I was expecting a separate commit so this result surprised me, but I was grasping at straws anyway so I kept going.

I then pushed bad-branch-copy to GitHub and created a pull request from bad-branch-copy to develop. This triggered a build on bad-branch-copy -> develop, which was successful.

At that point, buddybuild showed a successful build on bad-branch-copy -> develop and still showed a failure on bad-branch -> develop. However, Bitbucket showed a successful build on the pull request for bad-branch. Yes, that's right: buddybuild showed a failure but Bitbucket said it was ok.

We were then able to merge the bad-branch pull request and all was well with the world. Please don't ask me why, I will not answer. :)

I think the same thing could be accomplished with

git checkout bad-build

git checkout -b bad-build-copy

git push origin bad-build-copy

followed by creating a pull request for bad-build-copy.

 类似资料: