通常会有一个产生战争的Web管理项目，以及一个产生不同战争的API项目。每个都可以在具有不同防火墙规则的不同服务器上运行（在生产中）常见的部分是服务和域层。此外，可能还有其他可选的组件，这些组件也可以从爆炸插件中受益。爆炸插件允许分离，但允许开发人员一起查看和修改所有源，就像它是一个巨大的项目一样。
在grails 2.5中设置它很简单：
要构建项目，您只需在web admin app文件夹中执行grails war。
辉煌。轻松有效。开发人员只需从git中检出这两个项目，然后关闭它们。与intellij 14无缝协作也可以作为奖励（我们没有15岁以上的许可证，所以没有grails 3支持）
在我们考虑转移到grails 3之前，我们需要能够做同样的事情。
我们只能在主题上找到一个post。
这需要对两个项目上方的目录中的gradle脚本进行大量“黑客攻击”并创建脚本，这对于git来说并不理想。
在“保持干燥”一节中，他们将一些东西从子项目build.gradle文件移动到项目上方的build.gradle文件中。这需要吗？
新的主gradle文件有两次“存储库{mavenLocal（）..”。一旦在buildcript下面的顶部，然后再次在“subprojects {project-＆gt;”下。它是否正确？它应该不只是在主项目上，还是只在两个子项目中，而不是全部3个项目？
如果我们引入可选的爆炸插件（具有不同的依赖关系），则必须由每个开发人员手动编辑父gradle。这使得版本和控制变得困难。
该文章将弹簧安全核心添加到“插件域”，而不是Web应用程序项目。肯定安全性被添加到Web应用程序，而不是服务/域层插件？ API应用程序项目具有不同的安全要求。
有没有人用grails 3更好的方法，还是我们坚持使用grails 2.5？我们需要的grails 3中没有任何功能，但在某些时候，2.5将变得太旧，迁移看起来在大多数情况下是不可行的。事实上，没有经济实惠的IDE集成grails 3支持类似于intellij ultimate或者GGTS也是一个很大的负面因素。
答案 0 :(得分：1)
“黑客”不是必需的。 这是官方的多项目教程： http://guides.grails.org/grails-quickcasts-multi-project-builds/guide/index.html
mavenLocal（） - 是一个本地文件夹，用于存储项目的所有依赖项。 “buildscript”块仅控制buildscript进程本身的依赖关系，而不是顶级“依赖关系”块控制的应用程序代码。因此，您可以为“buildscript”和“dependencies”创建不同的存储库。
阅读Gradle用户指南以获取更多信息。 Gradle比旧Grails构建系统更难，但更强大。
我将项目从grails 2移动到3，我对结果很满意。
IntelliJ 2016 - 2017与grails 3完美配合
答案 1 :(得分：0)
我发现并关注this tutorial，这与大多数其他教程不同，因为它使用create-plugin而不是create-app作为插件。
然后该项目可以与eclipse neon 2一起正常工作。