7

最近一直在使用 Google App Engine，偶然发现了一些对我来说很神秘的东西，也许你可以澄清一下。

根据谷歌自己的一些网站（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_cron。

我需要所有这三个目标，有什么方法可以让他们依靠一个依赖？

在此先感谢，希望有人可以帮助我。

萨沙

4

2 回答 2

6 
<plugin>
<groupId>com.google.appengine</groupId>
<artifactId>appengine-maven-plugin</artifactId>
<version>${appengine.maven.plugin.version}</version>
</plugin>

第一个是基于前一个（但未弃用）appcfg（或Java SDK）。

它提供了许多特定于 App Engine 的目标，包括开发服务器和部署的基本目标，还有更新队列、更新 cron、更新索引、真空索引等。

<plugin>
<groupId>com.google.cloud.tools</groupId>
<artifactId>appengine-maven-plugin</artifactId>
<version>1.1.0-beta</version>
</plugin>

它是最新的，仍处于测试阶段。它基于GCloud SDK并具有一组有限的目标。

在这里你可以看到来自 Maven Central 的最新版本，最新的是1.0.0，我没有看到1.1.0-beta版本

如何选择合适的插件：如果你只需要使用dev-server并且deploy可以使用基于GCloud SDK.

这两个目标也可在appcfg基于插件中使用，但如果您需要更具体的目标（如处理队列、cron、索引等），则只能使用最后一个。

此外，Google Cloud Endpoints 目标仅适用于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。

这是另一个讨论同一主题的线程：`gcloud app deploy` vs. `appcfg.py`

于 2016-11-16T18:03:21.253 回答
2

两个插件的官方文档链接如下：

com.google.appengine groupId

com.google.cloud.tools groupId

两个插件都受支持，它们具有相同的 artifactId ( appengine-maven-plugin)，但目标不同且行为不同。我认为这是谷歌组织软件进化的另一个糟糕案例。他们可以简单地保留一个插件，并通过检查它们在环境中的存在、发布警告/建议等来透明地从一个 SDK 移动到另一个 SDK。

于 2017-06-28T16:45:49.320 回答