本文介绍了eclipse gradle工作空间解决gradle项目不工作的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

2个gradle项目,A和B,其中A具有编译依赖于B的定义。 JAR的重新映射为maven& gradle项目。我试过用自定义工具模型启用和禁用。我在init.d目录下的文件中定义了本地存储库。

问题1:为什么在解决A的依赖关系时,为项目B得到一个依赖性不足的错误?即使B未部署到任何存储库,本地工作区解析应该以与maven项目相同的方式启动并解决它(这是可以工作的顺便说一句)。



问题2:除了在build.gradle中定义的组和版本之外,B还需要什么特别的东西才能用于工作空间解析?

我使用eclipse 4.4运行。 1和Gradle IDE 3.7.0.201503301651-CI-B39。



使用--debug运行时,我可以看到gradle试图从本地存储库解析并放弃吗?

p>

解决方案

你的问题的答案归结为没有工作区解析的事实,因为你可能从maven / m2e知道它。



依赖关系的'重新映射'确实不会在工作空间中'解析'项目,因为它将工作空间视为某种类型的存储库。

相反,依赖关系通常由Gradle从您在构建脚本中定义的任何存储库中解析。然后,工具将尝试确定是否有一些已解决的jar依赖关系与工作区中的项目相对应。然后它用项目依赖项'替换'(或'重新映射')jar依赖项。

所以,这意味着你至少必须将jar发布到某个地方它可以在重映射开始之前解决。(从这一点开始,你不必重新发布你的罐子,因为解决的罐子不是'最新的')无关紧要。)



其他一些有用的信息可以帮助您了解...




  • 重新映射仅适用于工具管理的依赖关系,因此您必须启用依赖关系管理。

  • ,这使得'flat file'回购不起作用。可能会有其他情况受到类似错误的影响。如果遇到这些错误,你应该报告这些错误。 (Allthough我自己没有多少运气让自己的Gradle民众关注flatfile的bug)

2 gradle projects, A and B where A has compile dependency on B defined. Remappig of JARs is enabled for maven & gradle projects. I've tried with custom tooling model enabled and disabled. I have local repositories defined in a file under init.d directory.

Question 1: Why do I get an error of undersolved dependency for project B while resolving dependencies for A? Even though B isn't deployed to any of the repositories local workspace resolution should kick in and resolve it in same way as it is for maven projects (that works btw).

Question 2: Does B need to have anything special apart from group and version defined in build.gradle to be visible for workspace resolution?

I am running with eclipse 4.4.1 and Gradle IDE 3.7.0.201503301651-CI-B39. I've also tried stable release with same eclipse version.

When running with --debug I can see gradle trying to resolve from local repositories and than giving up?

解决方案

The answer to both your question boils down to the fact that there is no workspace resolution as you might know it from maven / m2e.

The 'remapping' of dependencies does not 'resolve' projects in the workspace in the sense that it treats the workspace as some kind of a repository.

Instead dependencies are resolved as normally by Gradle from whatever repositories you have defined in your build scripts. Then the tooling will attempt to determine if some of the resolved jar dependencies correspond to projects in your workspace. It then 'replaces' (or 'remaps') the jar dependency with a project dependency.

So, this means that you must at least publish the jar to some place where it can be resolved before the remapping can kick in. (From that point on you do not have to republish your jars as it doesn't really matter that the resolved jar isn't 'up-to-date')

Some other things that may be useful to know...

  • remapping is only applied to tooling managed dependencies, so you must have 'dependency management' enabled.

  • There's a bug that makes this not work for 'flat file' repo. There could be other cases affected by similar bugs. You should report such bugs if you run into them. (Allthough I didn't have much luck myself getting the Gradle folk's attention about the flatfile bug)

这篇关于eclipse gradle工作空间解决gradle项目不工作的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持!

08-11 05:42