Gradle 可以处理除子目录之外的本地依赖关系吗?

发布于 2024-09-16 00:49:44 字数 493 浏览 5 评论 0原文

我不知道我的概念是否完全错误,但我想创建几个依赖于其他项目的项目,这些项目不属于父项目的目录结构。我知道执行此操作的正常方法是使用从某些外部存储库获取的外部依赖项。但在这种情况下,假设在名为“F”的项目中开发了一个框架,该框架在项目“P”中使用,那么 P 使用 F,但 F 在 IMO 中不一定是 P 的子项目,因为 P 是仅用于测试驱动F的开发(但不仅仅是单元测试)。在此过程的后期,当 F 稳定时,F 就会被分离出来,并且可以通过存储库被其他项目使用。但在以 P 作为测试用例的 F 开发过程中,如果可以省略存储库的往返过程,那就太好了。

更糟糕的是,对于初始开发,有多个测试驱动的消费者项目,它们都需要依赖于 F,但不能通过外部存储库。

我的想法是在磁盘上的某个位置使用它自己的 git 存储库来开发 F。其他类似 P 的项目驻留在磁盘上的其他位置,并且具有基于本地文件系统的对 F 的依赖。在 Gradle 中这样的构造可能吗?如果是这样,我从哪里开始?我扫描了 Java 示例,但找不到合适的示例。

有什么想法吗?

I don't know if I totally got the concept wrong, but I want to create several projects with dependencies to other projects which are not part of the directory structure of a parent project. I know that the normal way of doing this would be to use an external dependency which fetches from some external repository. But in this case, where let's say in project called 'F' a framework is developed, which is used in project 'P'., then P uses F, but F should IMO not necessarily be a sub-project of P as P is only used to test-drive the development of F (but it's not only a unit test). Later in the process, when F is stable, F is separated and can be consumed by other projects via a repository. But during development of F with P as it's test case, it would be nice if that round-trip through the repository could be omitted.

To make matters worse, for the initial development there is more than one test-driving consumer project, which all need to have a dependency to F, but not via an external repository.

My idea is to develop F in some place on the disk with it's own git reposity. The other P like projects reside somewhere else on the disk and have a local file system based dependency to F. Would such a construct be possible in Gradle? If so, where do I start? I scanned the Java examples but couldn't find an appropriate example.

Any ideas?

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

扫码二维码加入Web技术交流群

发布评论

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

评论(2

看轻我的陪伴 2024-09-23 00:49:44

Gradle 项目层次结构是完全虚拟的。它只是默认物理位置对应于虚拟层次结构。但你对此有完全的控制权。请参阅:http://gradle.org/0.9- rc-1/docs/userguide/build_lifecycle.html#sec:settings_file

关于您的其他想法,请查看以下 Jira:http://jira.codehaus.org/browse/GRADLE-1014

The Gradle project hierarchy is fully virtual. It just has the default that the physical location corresponds to the virtual hierarchy. But you have complete control over this. See: http://gradle.org/0.9-rc-1/docs/userguide/build_lifecycle.html#sec:settings_file

Regarding your other ideas have a look at the following Jira: http://jira.codehaus.org/browse/GRADLE-1014

雨落星ぅ辰 2024-09-23 00:49:44

您可以考虑这样的文件夹层次结构:

Main folder
|- F folder
|  |- .git
|  |- sources
|  |- build.gradle (with parts specific to F)
|- P folder
|  |- sources
|  |- build.gradle (with part specific to P)
|- build.gradle (with common parts)
|- settings.gradle

因此您始终可以决定在 F 项目、P 项目或两个项目上运行 gradle。它还允许您单独推广您的 F 项目,而无需 P 或任何其他副项目。

如需了解更多最新信息,请查看多项目构建章节 Gradle 文档。

You could consider a folder hierarchy like this one:

Main folder
|- F folder
|  |- .git
|  |- sources
|  |- build.gradle (with parts specific to F)
|- P folder
|  |- sources
|  |- build.gradle (with part specific to P)
|- build.gradle (with common parts)
|- settings.gradle

So you can always decide to run gradle on either the F project, the P project or the two alltoegether. It will also allows you to promote you F project alone without the P or any other side projects.

For more up-to-date information, check the Multi Project Builds chapter of the Gradle documentation.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文