有一个产生战争的web管理项目和产生不同战争的API项目是很常见的。每个可以运行在具有不同防火墙规则的不同服务器上（生产中）。常见的部分是服务和领域层。另外，可能还有其他可选的组件，它们也可以从爆炸插件中受益。分解插件允许分离，但允许开发人员查看和修改所有源代码，就像它是一个巨大的项目一样。grails 3创建子项目
Grails中2.5这一设置是微不足道的：
- 在你的项目根目录中创建您的Web管理应用
- 建立自己的核心业务应用程序作为项目的根
- 一个插件添加一条线你的web管理器项目BuildConfig.groovy使用服务项目作为分解插件，例如“grails.plugin.location.coreservices =”../coreservices“”
要构建项目，您只需在Web管理员应用程序文件夹中进行grails战争。
太棒了。轻松有效。开发人员只需从git签出两个项目，然后离开他们。与intellij 14无缝地工作也是一种奖励（我们没有15+的许可证，遗憾的是没有grails 3的支持）
在我们考虑转向grails 3之前，我们需要能够做同样的事情。
关于这个问题，我们只能找到一个post。
这需要对gradle脚本进行大量的“黑客行为”，并在两个项目上方的目录中创建脚本，这对于使用git并不理想。
在“保持干活”部分，他们将一些东西从子项目build.gradle文件移动到项目上方的build.gradle文件中。这是必需的吗？
新的主gradle文件有两个“repositories {mavenLocal（）..”。一次在buildscript的顶部，然后再次在“子项目{project->”下。它是否正确？它不应该只是在主要项目上，还是只在两个子项目上，而不是全部3个？
如果我们引入可选的分解插件（具有不同的依赖关系），每个开发人员必须手动编辑父gradle。这使得版本和控制变得困难。
本文将spring security core添加到“插件域”，而不是web应用程序项目。当然，安全性已添加到Web应用程序中，而不是服务/域插件？一个API应用程序项目会有不同的安全需求。
有没有人有更好的方法与Grails 3，或者我们应该坚持Grails 2.5？在我们需要的Grails 3中没有任何特性，但是在某些时候，2.5会变得过于老化，大多数情况下迁移看起来是不可行的。事实上没有负担得起的IDE集成了类似于intellij ultimate或GGTS的grails 3支持，这也是一个很大的负面因素。