最近一直在与Google App Engine合作,偶然发现了一些对我来说很神秘的事情,也许你可以澄清一下。
根据Google自己的一些网站(https://cloud.google.com/appengine/docs/java/tools/maven),您应该使用
<plugin>
<groupId>com.google.appengine</groupId>
<artifactId>appengine-maven-plugin</artifactId>
<version>${appengine.maven.plugin.version}</version>
</plugin>
并根据其他一些页面(https://cloud.google.com/appengine/docs/java/tools/maven-reference),你应该使用
<plugin>
<groupId>com.google.cloud.tools</groupId>
<artifactId>appengine-maven-plugin</artifactId>
<version>1.1.0-beta</version>
</plugin>
现在我真的很困惑我应该使用哪个。为什么首先有两个版本?
我面临的问题:
两者似乎都支持不同的目标。一个支持部署等,另一个支持update和update_cron。
我需要所有这三个目标,无论如何我都可以拥有一个依赖目标吗?
提前致谢,希望有人能帮助我。
的Sascha
答案 0 :(得分:6)
<plugin>
<groupId>com.google.appengine</groupId>
<artifactId>appengine-maven-plugin</artifactId>
<version>${appengine.maven.plugin.version}</version>
</plugin>
第一个基于之前的(但未弃用)appcfg
(或Java SDK
)。
它为App Engine提供了lot of Goals,其中包括dev-server和deploy的基本版本,以及更新队列,更新cron,更新索引,真空索引等......
<plugin>
<groupId>com.google.cloud.tools</groupId>
<artifactId>appengine-maven-plugin</artifactId>
<version>1.1.0-beta</version>
</plugin>
这是最新的,仍处于测试阶段。它基于GCloud SDK
并且目标有限。
Here您可以看到Maven Central的最新版本,最新版本为1.0.0
,我看不到1.1.0-beta
版本
如何选择合适的插件:
如果您只需要使用dev-server
和deploy
,则可以使用基于GCloud SDK
的最新插件。
基于appcfg
的插件中也提供了这两个目标,但如果您需要更多特定目标(例如处理队列,cron,索引......),则只能使用最后一个目标。
此外,Google Cloud Endpoints goals仅适用于appcfg
一个
最后,这两个插件可以在同一个项目中共存。使用它们的技巧是使用目标完整路径而不是短路径(source)。
例如:
com.google.cloud.tools:appengine-maven-plugin:run
com.google.appengine:appengine-maven-plugin:devserver
而不是
appengine:run
appengine:devserver
如果使用较短的版本,Maven无法解析正确的groupId(因为artifactId在两个插件上都是相同的)
目前这两个插件都在运行,并且没有基于appcfg
的插件的弃用痕迹。
以我为例,我总是在GCloud插件中使用部署(我认为与appcfg插件相比,部署程序稍微好一点),但是当我需要更新cron / queues时,我使用上一个插件的目标。我在项目中同时使用它们没有任何问题
请记住,如果您想使用基于GCloud的设备,则需要在本地计算机上安装GCloud installed(并已配置)。
以下是讨论同一主题的另一个主题:`gcloud app deploy` vs. `appcfg.py`
答案 1 :(得分:2)
这两个插件的官方文档链接如下:
com.google.appengine groupId
com.google.cloud.tools groupId
两个插件都受支持,它们具有相同的artifactId(appengine-maven-plugin
),但目标不同,行为也不同。我认为这是谷歌软件演变组织不良的另一个案例。他们可以简单地保留一个插件,并通过检查它们在环境中的存在,发布警告/建议等,从一个SDK透明地移动到另一个SDK。