我们目前正在使用grails插件功能在相关组件之间共享域模型。以下是我们所看到的的一个经过净化的例子
- 产品域插件-[版本].zip
- 产品管理员-〔版本〕.war
- 产品经理-[版本].war
- 产品移动服务-〔版本〕.war
在开发者工作站上，我们有一个文件夹结构，看起来像这样：
code/
├── product-domain-plugin/
├── product-admin/
├── product-manager/
├── product-mobile-services/
每个项目都是自己的git存储库，使用git-flow约定。例如，在开发product-admin的过程中，我们将在BuildConfig.groovy:中内联product-domain-plugin
grails.plugin.location.productdomainplugin = "../product-domain-plugin"
对于产品发行版，我们将product-domain-plugin打包为插件，将其部署到我们的内部artifactory服务器，并将其称为product-domain-plugin-4.0.zip。
在每个product-* grails应用程序的发布分支中，我们修改BuildConfig.groovy文件以获取插件的打包版本（这样我们就可以保证构建环境与共享域代码一起进行版本控制）：
compile ':product-domain-plugin:4.0'
当应用程序通过jira发布时，构建服务器会检查出引用外部插件的主分支，并构建工件（看起来像product-admin-4.0.war）。
我们为什么要这样做？
- 我们将grails项目分开，这样我们就可以在不影响其他项目的情况下更新其中一个项目（例如，在不重新标记管理应用程序的情况下修复移动服务）
- 通过使用打包插件而不是内联插件，构建的每个部分仍然是版本化的
- 开发人员可以选择只签出他需要的组件，如
product-mobile-services，并依赖最新版本的域插件 - 我们已经建立了一个版本号约定，这意味着版本为x.y.z的grails应用程序是用版本为x.y的打包域插件构建的，并且有一个修补程序z
然而，我们经常发现自己同时在插件和grails应用程序中开发该功能（因此产生了内联配置）。本质上，我们能判断插件是否有效（或者正是我们需要的）的唯一方法是在网络应用程序下测试它。最终部署的war文件没有内联的域插件。所以按顺序：
- 在特定版本将域插件构建/部署到我们的artifactory服务器
- 修改所有grails应用程序以使用来自artifactory服务器的插件的打包版本
- 通过grails应用程序的正常QA测试并发布它们
问题是，如果/当在步骤1中发现域插件的问题时。没有办法对插件进行QA测试，因为它只与其他grails应用程序交互。当检测到并解决了问题时，我们会更新域插件的版本号（因为grails认为上一个插件已经发布，并正确地从服务器缓存了工件），然后重新部署到我们的服务器。这在QA测试过程中可能会变得乏味，而且似乎可以改进。
我曾想过使用git子模块来实现这一点，但域插件子模块似乎需要成为每个grails应用程序的一部分。为3个grails项目保持同一域插件存储库的3个不同克隆的最新状态似乎会非常混乱。
很抱歉看到文字墙了。希望我已经把一切都说清楚了。肯定有更简单的方法来管理这件事吗？欢迎提出任何建议。
在发布到您的Artifactory存储库之前，您可以尝试使用maven本地存储库作为本地问答测试的中间私有发布点。我们的联合应用程序/插件开发的正常工作流程如下：
-
使用应用程序BuildConfig.groovy中的内联插件配置开发应用程序/插件中的功能，并运行测试、运行应用程序。
-
使用插件的SNAPSHOT发布版本测试插件解析和打包。将"-SNAPSHOT"附加到您正在开发的插件版本，并使用"maven install"将其发布到本地maven存储库。更新应用程序中的插件配置以删除内联依赖项，将其替换为"compile"语句和插件的SNAPSHOT版本。刷新依赖项将从本地存储库中提取插件并编译整个应用程序。使用运行测试和运行战争来测试应用程序，以确保打包和部署能够正常工作。
-
从版本号中删除-SNAPSHOT后，将插件的发布版本发布到artifactory。更新应用程序BuildConfig.groovy以引用已发布的插件，并重新执行运行测试和运行战争命令。
这将大大减少您暴露在插件打包问题中的风险。maven intall和SNAPSHOT支持是Grails本身的一部分。