googlecloudplatform/google-cloud-eclipse

Google Cloud Platform plugin for Eclipse

Deprecation Note: Cloud Tools for Eclipse is only compatible with the App Engine Java 8 runtime, which will reach the end of support on January 31, 2024. After this date, your existing Java 8 applications will continue to run and receive traffic. However, you cannot deploy new or update existing applications that use runtimes after their end of support date. We recommend that you migrate to the latest supported version of Java.

This project provides an Eclipse plugin for building, debugging, and deploying Google Cloud Platform applications.

End user documentation and installation instructions can be found on cloud.google.com.

TL;DR: mvn package should generate a p2-accessible repository in gcp-repo/target/repository.

Development

This project is built using Maven Tycho, a set of extensions to Maven for building Eclipse bundles and features.

Requirements

1. The Google Cloud SDK; install this somewhere on your file system and add it to your path.

2. Install the App Engine Java components:

   $ gcloud components install app-engine-java

3. JDK 8

4. The Eclipse IDE. It's easiest to use the Eclipse IDE for Java EE Developers package. You must use Eclipse 4.8 - 4.21 (versions since 4.22 are currently not supported). We use target platforms to support building for earlier versions of Eclipse. You also need the following:

   1. The M2Eclipse plugin (also called m2e) is required to import the projects into Eclipse. M2Eclipse is included in several packages, such as the Eclipse IDE for Java EE Developers package.

   2. The m2e connector for maven-dependency-plugin should be installed from http://ianbrandt.github.io/m2e-maven-dependency-plugin/. This connector should be prompted for by M2Eclipse. If not, use Preferences > Maven > Discovery > Open Catalog and search for Dependency and install.

   3. The Google Java Format plugin for Eclipse. Download the latest version and place the jar into your Eclipse installation's dropins/ directory (on MacOS this may be in Eclipse.app/Contents/Eclipse/dropins/).

5. Maven 3.5.0 or later. Although m2eclipse is bundled with its own Maven install, Maven is necessary to test command-line builds.

6. git (optional: you can use EGit from within Eclipse instead)

7. Clone the project to a local directory using git clone https://github.com/GoogleCloudPlatform/google-cloud-eclipse.git.

Running Tests

If you're using Goobuntu, first point JAVA_HOME at a stock OpenJDK, not at the Google JDK:

$ export JAVA_HOME=/usr/lib/jvm/java-8-openjdk-amd64

If all you want is to run tests, just do mvn verify.

However, the integration tests will interfere with your display, disrupt your using your computer, and likely fail if you touch the screen while the integration tests are running. A nice solution on Unix-like systems is to do xvfb-run mvn verify. (Install Xvfb if necessary.) xvfb-run will use a virtual display, and you and the tests will not be disrupted.

Configuring Maven/Tycho Builds

The plugin is built using Maven/Tycho and targeted to Java 8.

The tests need to find the Google Cloud SDK. You can either:

1. Place the SDK/bin directory on your PATH
2. Set GOOGLE_CLOUD_SDK_HOME to point to your SDK

Changing the Eclipse Platform compilation and testing target

By default, the build is targeted against Eclipse 2018-09 (4.9). You can explicitly set the eclipse.target property to 2018-12 (4.10).

$ mvn -Declipse.target=2018-12 package

Adding a new bundle/fragment

We normally put production code into a bundle and tests as a fragment hosted by that bundle, put under the plugins/ directory. For now we have been committing both the pom.xml and Eclipse's .project, .classpath, and .settings/ files. We have a master set of project settings in eclipse/settings; see the README.md for more details.

Our CI process is configured to run our tests with JaCoCo, which requires some additional configuration to add new bundles and fragments in build/jacoco/.

Import into Eclipse

We pull in some dependencies directly from Maven-style repositories, such as Maven Central and the Sonatype staging repository, which isn't directly supported within Eclipse. We have a few hoops to jump through to set up a working development environment.

Assemble the IDE Target Platform

The Eclipse IDE and Tycho both use a Target Platform to manage the dependencies for the source bundles and features under development. Although Tycho can pull dependencies directly from Maven-style repositories (like Maven Central), Eclipse cannot. So we use Tycho to cobble together a target platform suitable for the Eclipse IDE with the following command.

$ (cd eclipse; mvn -Pide-target-platform package)        # may want -Declipse.target=XXX

This command creates a local copy of the target platform, including any Maven dependencies, into eclipse/ide-target-platform/target/repository. You will use this repository to create a target platform within the IDE, as described below.

The Eclipse version used for the target platform is affected by the eclipse.target property, described below.

You must regenerate the target platform and reconfigure the IDE's target platform whenever dependencies are updated.

Steps to import into the Eclipse IDE

1. Setup JDK 8 in Eclipse (this may already be set up by Eclipse's JRE/JDK auto-discovery)

   1. Select Window/Preferences (on Mac Eclipse/Preferences).

   2. Under Java/Installed JREs click Add.

   3. Select Standard VM and click Next.

   4. Select the folder that contains the JDK 8 installation by clicking Directory.

   5. Click Finish.

   6. Select Java/Installed JREs/Execution Environments page.

   7. Click on JavaSE-1.8 in the list on the left under Execution Environments:.

   8. The JDK just added should show up in the list on the right along with other installed JDKs/JREs. Set the checkbox next to the JDK 8 added in the previous steps to mark it as compatible with the JavaSE-1.8 execution environment.

   9. Click OK.

2. Set up the Target Platform: you will need to repeat this process whenever items are changed in the target platform, such as a new release of the appengine-plugins-core.

   1. As described above, you must first build the target platform with Maven:

      $ (cd eclipse; mvn -Pide-target-platform package)

   2. Open the Preferences dialog, go to Plug-in Development > Target Platform.

   3. Click Add... > Nothing to create a new Target Platform.

   4. Name it GCP IDE Target Platform.

   5. Select Add > Software Site.

   6. Select the Add... button (found beside the Work with: field) and then select Local to find a local repository. Navigate to .../eclipse/ide-target-platform/target/repository, and click OK.

   7. Once the main content populates, check the Uncategorized item to pull in all items. Click Finish.

   8. Click Finish to complete the new target platform definition.

   9. Select your new target platform (instead of Running Platform) in the Target Platform preferences.

   10. Click Apply and Finish to load this new target platform.

   11. Eclipse will load the target.

3. Import the projects.

   1. Select File/Import... menu in Eclipse.

   2. Select Existing Maven Projects from the list.

   3. Click Browse... and select the directory that contains the project.

   4. Under Projects: the pom.xml files representing modules should be displayed. Make sure that all of them are selected except verify_feature_completeness and the sub-directories under eclipse. You probably need to explicitly unselect these projects. Click Finish.

      • The subprojects under the eclipse directory define target platforms for the Tycho build. It's easier to edit the files from the eclipse-setup project.

   5. Maven may prompt you to install several additional plugin connector plugins from Tycho if they are not already installed. Click Finish to install them. If Eclipse prompts you to install any other plugins, do so.

   6. Restart Eclipse when prompted.

4. Check the imported projects.

   • There should be no errors in the Markers or Problems views in Eclipse. However you may see several low-priority warnings.

     • You may see Maven-related errors like "plugin execution not covered by lifecycle configuration". If so, right-click on the problem and select Quick Fix > Discover new m2e connectors and follow the process to install the recommended plugin connectors.

5. Create and initialize a launch configuration:

   1. Right-click the gcloud-eclipse-tools.launch file under the google-cloud-eclipse module in the Package Explorer.

   2. Select Run As > Run Configurations...

   3. Set variables required for launch:

      1. Go to the second tab for Arguments

      2. Click the Variables... button for VM argument:

      3. Click the Edit variables... button

      4. Click New...

      5. Set the name to oauth_id, and the value to the value you want to use (description optional)

      6. Click OK, the variable will appear in the list

      7. Repeat steps 6-8 but use oauth_secret as the name and use the corresponding value

      8. Click OK to close the edit variables dialog

      9. Click Cancel to close the variable selection dialog

      10. Click Apply to apply the changes to the run config

   4. From the Run menu, select Run History > gcloud-eclipse-tools. A new instance of Eclipse launches with the plugin installed.

Updating Target Platforms

Updating the .target files

We use Target Platform files (.target) to collect the dependencies used for the build. These targets specify exact versions of the bundles and features being built against. We currently maintain three target platforms, targeting the latest version of the current, previous, and next releases. This is currently:

• Eclipse 2018-09 (4.9): eclipse/eclipse-2018-09/gcp-eclipse-2018-09.target
• Eclipse 2018-12 (4.10): eclipse/eclipse-2018-12/gcp-eclipse-2018-12.target

These .target files are generated and should not be manually updated. Updating .target files directly becomes a chore once it has more than a couple of dependencies. We instead generate these .targets from Target Platform Definition .tpd files. The .tpd files use a simple DSL to specify the bundles and features, and the location of the repositories containing them. The .tpd files are processed using the TPD Editor which resolves the specified dependencies and creates a .target. The process is:

1. Install the TPD Editor, if necessary
   • Use Help > Install New Software and specify https://download.eclipse.org/cbi/tpd/3.0.0-SNAPSHOT/ as the location.
   • Restart Eclipse when prompted
2. Open the .tpd file in Eclipse.
3. Make any necessary changes and save.
   • Note that the TPDs specify artifacts using their p2 identifiers. Bundles are specified using their OSGi Bundle Symbolic Name (e.g., org.eclipse.core.runtime). Features are specified using their Feature ID suffixed with .feature.group (e.g., org.eclipse.rcp.feature.group).
4. Select the file in the Package Explorer, right-click, and choose Create Target Definition File to update the corresponding .target file.

Both the .tpd and .target files should be committed.

Updating Dependencies

The IDE Target Platform needs to be rebuilt at the command line and reimported into Eclipse when dependency versions are changed:

1. (cd eclipse; mvn -Pide-target-platform package)
2. Preferences > Plug-in Development > Target Platforms
3. Select your target ("GCP IDE Target Platform") and click Edit
4. Select the location and click Reload to cause any cached info to be discarded.
5. Click Edit and then select Uncategorized.
6. Finish / OK until done.

Updating the Eclipse IDE Target Platforms

The IDE Target Platform, defined in eclipse/ide-target-platform, may need to be updated when dependencies are added or removed. The contents are defined in the category.xml file, which specifies the list of features and bundles that should be included. This file can be edited using the Category editor in Eclipse. Ideally the version should be specified as "0.0.0" to indicate that the current version found should be used. Unlike the .tpd file, the identifiers are not p2 identifiers, and so features do not require the .feature.group suffix.

Other Miscellaneous Dev Tasks

Updating IDE settings

See eclipse/settings/ for details.

Configuring Maven/Tycho Toolchains for new JDK releases

Now that OpenJDK is moving to a 6-month release cycle...

We use Tycho's support for Maven Toolchains to ensure that new language features do not creep into the code. Tycho's support is automatically enabled in the build when compiling with a newer JDK than our minimium supported platform. When using such a JDK, currently anything later than JDK 8, we configure the Tycho compiler plugin to use the useJDK=BREE setting to ensure bundles are compiled with a JDK that matches the bundle's Bundle-RequiredExecutionEnvironment. However we leave tycho-surefire to run the tests using the current toolchain (the default for useJDK=SYSTEM) so as to catch any non-backwards compatible changes.

These settings require configuring Maven's toolchains to point to appropriate JRE installations. Tycho further requires that a toolchain defines an id for the specified Execution Environment identifier. For example, a ~/.m2/toolchains.xml to configure Maven on macOS for 8, and 11 toolchains might be:

<?xml version="1.0" encoding="UTF8"?>
<toolchains>
  <toolchain>
    <type>jdk</type>
    <provides>
      <id>JavaSE-11</id>
      <version>11</version>
      <vendor>openjdk</vendor>
    </provides>
    <configuration>
      <jdkHome>/Library/Java/JavaVirtualMachines/jdk-11.jdk/Contents/Home</jdkHome>
    </configuration>
  </toolchain>
  <toolchain>
    <type>jdk</type>
    <provides>
      <id>JavaSE-1.8</id>
      <version>1.8</version>
      <vendor>oracle</vendor>
    </provides>
    <configuration>
      <jdkHome>/Library/Java/JavaVirtualMachines/jdk1.8.0_181.jdk/Contents/Home/jre</jdkHome>
    </configuration>
  </toolchain>
</toolchains>

Note that jdkHome for JavaSE-1.8 specifies the jre/ directory: Tycho sets the default boot classpath to jdkHome/lib/*, jdkHome/lib/ext/*, and jdkHome/lib/endorsed/*. For many JDKs, including Oracle's JDK and the OpenJDK prior to Java 9, those directories are actually found in the jre/ directory. Compilation errors such as java.lang.String not found and java.lang.Exception not found indicate a misconfigured jdkHome. With the introduction of Java modules with Java 9, there is no longer a separate JRE distribution.

google-cloud-eclipse's Issues

Remove junit dependency from localserver/pom.xml

License in feature.xml

Make sure we know what the license is, then add it to the license element in feature.xml

Re-implement App Engine deploy

The code moved from the legacy plugin depends on an old version of gcloud to do the deploy, but that capability has been removed. The current implementation needs to be modified to use either the gcloud-maven-plugin or the app-maven-plugin for deployment.

set up target platforms for Mars and Neon

as Brian did for the legacy plugin in https://github.com/GoogleCloudPlatform/google-plugin-for-eclipse/commit/79dae2c02a027fa6b2e7f9a530af84ed8f010993

set up CLA checks for the repo

cf. the legacy repo

plugin should provide new project templates

Just for tracking atm. We're going to need to design this feature first. Possibly based on maven archetypes.

Move version back to 1.0

instead of 94.0.0

Test the Generic Server Framework

ATM, there's no actual Java code in this project. It's all config. However at runtime it does actually produce configured Java classes that do things. Figure out how to write at least a basic test for some of this.

Work with non-default VM

Build instructions say:

"Set the checkbox selected for the JDK you just added to mark it as default."

We should figure out how to make this work without making JDK 7 the default since users may want to use a different JDK for other projects

Make icon square

Right now the App Engine icon is 18x16. and gets squished into a square. We need to get a 16x16 square icon.

Tutorial

For running and installing the plugin.

Enable specifying the api server host and port

When the App Engine dev app server is launched, it uses an api server to offer various administrative features. The user should be able to define what hostname and port the api server should bind to instead of using a fixed value (localhost and 8188 now).
This will affect com.google.cloud.tools.eclipse.appengine.localserver.server.CloudSdkServer

Use own icons instead of Eclipse internal icons

The class com.google.cloud.tools.eclipse.util.TerminateAction should use icons from from our bundle, instead of the one found in the internal code of the DebugPlugin.

Upgrading Appengine SDK breaks project

I generate a new web application project using the plugin. It depends on AppEngine SDK 1.9.30. after fixing the project setup to use jdk7, it compiles and deploys to App engine successfully. The 1.9.30 SDK is displayed as plugin and also as local directory from my $HOME, both are valid.
Then I upgrade the App Engine SDK bundle plugin to 1.9.34 from custom update site. It installs successfully.
When I restart Eclipse, the project still displays 1.9.30 as it's dependency, but Eclipse complains that it does not have any App Engine SDK on its build path, and also no SDK from bundle is displayed among the available SDKs.

App Engine deployment should support progress monitor and cancellation

Switch to gcloud

Instead of appengine-java-sdk.

I think this is the only file that needs to be changed:

gcloud-eclipse-tools/plugins/com.google.gcp.eclipse.appengine.localserver/gcloud_serverdef.xml

Refactor com.google.cloud.tools.eclipse.appengine.localserver plugin to separate concerns

The com.google.cloud.tools.eclipse.appengine.localserver plugin currently contains all code required to run web app on a local dev app server, but the UI and non-UI code should be separated into 2 plugins.

Furthermore the code that interacts with Cloud SDK/gcloud/dev_appserver.py should also be moved into its own plugin as other features will also depend on it (like e.g. support for App Engine Flex environment)

Also there are several utility classes (mostly the com.google.cloud.tools.eclipse.util package) that are currently used only in this plugin but can be useful in plugins implemented in the future, so these should also be moved into a separate plugin.

Implement integration tests with Cloud SDK

We should implement integration tests to ensure that the commands we construct are accepted by gcloud/dev_appserver.py (or any other utility we depend on).
These integration tests should run only if explicitly requested by the user when running the mvn build so as no to require each build environment to have Cloud SDK installed.
Possible solution is to use @category from JUnit, Tycho 0.25 introduced support for it.

Allow native WTP projects to be run/debug on dev app server

We currently support only Maven projects that has the gcloud-maven-plugin configured to be run/debugged on the local dev app server, see: com.google.cloud.tools.eclipse.appengine.localserver.facet.CloudSdkFacetInstallDelegate#execute()

We should allow for non-Maven WTP projects as well.

Add build instructions

1. How to build and test with Maven.
2. How to load into Eclipse and run and debug.

Rename repo cloud-tools-for-eclipse

Use gcloud for local server

What's the gcloud command to run a local dev server?

Verify separators in values for argument that expect a path

In com.google.cloud.tools.eclipse.appengine.localserver.ui.ServerFlagSelectionDialog when a user defines an argument that takes a file path as its value, we should verify that the separator character used corresponds to the separator character of the platform.

Change dev app server extension point ids, names, descriptions

The current values in /com.google.cloud.tools.eclipse.appengine.localserver/plugin.xml are either include implementation details (referring to Cloud SDK) or do not contain enough details and therefore ambiguous (e.g. com.google.cloud.tools.eclipse.facet).
We should change these values and through naming we should convey that these extension points are for App Engine/App Engine Standard related features in order to allow for App Enginge Flex, GCE, GKE related extension points that follow a standard naming convention. Also, if possible, we could shorten the current names from com.google.cloud.tools.eclipse.* to com.google.<env_type>.*, where env_type could be ae1/ae.std, ae.flex, gce, gke for instance.

Enable specifying debug port the dev app server

When the dev app server is launched in debug mode, it uses a random port the bind the debug port. We should allow the user to specify the debug port as part of the launch configuration. If the port is specified, it should be used in com.google.cloud.tools.eclipse.appengine.localserver.server.CloudSdkLaunchConfigurationDelegate.getDebugPort()

Use Maven toolchains to avoid inadvertent use of Java8 APIs.

see https://github.com/GoogleCloudPlatform/google-plugin-for-eclipse/pull/115

Add Mockito bundled as plugin to use in tests

The Eclipse Orbit provided Mockito and EasyMock bundles both have different issues that make them difficult or inconvenient to use for testing so we decided to create a bundle that contains Mockito explicitly and use that as a dependency in our tests.

setup automatic CLA check

One Google Cloud Platform for Eclipse Mars target

Whehn we setup a build we get two "Google Cloud Platform for Eclipse Mars" targets, though they're actually the same.

Set the checkbox next to one of the Google Cloud Platform for Eclipse Mars
target platforms (they are pointing to the same file), and click Apply.

See if we can figure out how to have only one.

Add/remove project to/from dev server

When the app engine local dev server is created, at the end of the wizard the user has the option to add resources (e.g. web applications) to the server. Also once the dev server is created, if the user right clicks on the instance and selects "Add and Remove..." she can add/remove resources to/from the server.
We should figure out how to enable this for app engine projects. Possible solutions:

• A new facet to the project to mark it an App Engine project?
• Inspecting it whether it has an appengine-web.xml file?

Use dev_appserver.py output to collect available command line flags

Once dev_appserver.py supports formatting its output as json, we should use that to gather the available flags that can be passed to it in the command line, affects com.google.cloud.tools.eclipse.appengine.localserver.server.CloudSdkServerFlags.getFlags()

Can we use gcloud devappserver to run Java apps?

https://cloud.google.com/sdk/gcloud-app#Running_locally

This seems to require app.yaml.

Perhaps after staging?

Point webappDirectory at the current project's webapp folder

i.e. the parent of WEB-INF

Analytics

Mac build problem

Figure out what's going on here:

Downloaded: https://repo.maven.apache.org/maven2/org/eclipse/tycho/org.eclipse.osgi/3.10.101.v20150820-1432/org.eclipse.osgi-3.10.101.v20150820-1432.jar (1276 KB at 2323.7 KB/sec)
[ERROR] [ERROR] Some problems were encountered while processing the POMs:
[FATAL] Non-resolvable parent POM for com.google.gcp.eclipse:com.google.gcp.eclipse.appengine.localserver:94.0.0-SNAPSHOT: Could not find artifact com.google.gcp.eclipse:trunk:pom:0.0.1-SNAPSHOT and 'parent.relativePath' points at wrong local POM @ line 5, column 11
@
[ERROR] The build could not read 1 project -> [Help 1]
[ERROR]
[ERROR] The project com.google.gcp.eclipse:com.google.gcp.eclipse.appengine.localserver:94.0.0-SNAPSHOT (/Users/elharo/gcloud-eclipse-tools/plugins/com.google.gcp.eclipse.appengine.localserver/pom.xml) has 1 error
[ERROR] Non-resolvable parent POM for com.google.gcp.eclipse:com.google.gcp.eclipse.appengine.localserver:94.0.0-SNAPSHOT: Could not find artifact com.google.gcp.eclipse:trunk:pom:0.0.1-SNAPSHOT and 'parent.relativePath' points at wrong local POM @ line 5, column 11 -> [Help 2]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/ProjectBuildingException
[ERROR] [Help 2] http://cwiki.apache.org/confluence/display/MAVEN/UnresolvableModelException

Autolocate gcloud SDK if present

Rather than making user select it.

Autolocate App Engine SDK if present

Rather than making user find it

Filter gcloud output when checking installed components

When we check whether the required components are installed for gcloud the command returns all components with their corresponding status. We should use the new filter option to be released soon (soon wrt 4/15/2016) to reduce the output from gcloud to the necessary components. Most likely the following command will give the desired result:
gcloud components list --filter=id:app-engine-java --format='value(state.name)'

Eclipse crashes after opening deployed GAE app in browser

On linux, after the deployment of a GAE/GWT application (simple project generated via GPE's new web application feature) finished, and Eclipse tries to open the browser with the url of the app an segfault happens:

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x00007fc16ed69eaf, pid=27204, tid=27280
#
# JRE version: OpenJDK Runtime Environment (8.0) (build 1.8.0-google-v7-114555630-114530017)
# Java VM: OpenJDK 64-Bit Server VM (25.51-b03 mixed mode linux-amd64 compressed oops)
# Problematic frame:
# C  [libgdk-x11-2.0.so.0+0x4ceaf]  gdk_display_open+0x3f
#
# Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
#
# An error report file with more information is saved as:
# /tmp/gpe45_testing/eclipse-mars-upgradelorry/hs_err_pid27204.log
#
# If you would like to submit a bug report, please visit:
#   http://b.corp.google.com/createIssue?component=32554
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#

If the checkbox to open the app in browser after deploy (in the GPE deploy dialog) is cleared, the app deploys successfully, and Eclipse does not crash.
Possibly related:
Sloeber/arduino-eclipse-plugin#397
https://bugs.eclipse.org/bugs/show_bug.cgi?id=430736

continuous build

probably travis

JRE Whitelist Problem reports

This is the red squiggly lines under classes not supported by the App Engine Standard environment.

Use user-supplied command line flags

If the user specifies additional command line flags in the launch configuration for the App Engine dev server, the com.google.cloud.tools.eclipse.appengine.localserver.GCloudCommandDelegate.createAppRunCommand(String, String, String, String, int, int) method should add them to the constructed command.

Button to sync maven and launch configuration arguments

Add a button to com.google.cloud.tools.eclipse.appengine.localserver.ui.CloudSdkServerLaunchTab that allows the user to either pull the appropriate program args from Maven into the launch config, or vice-versa..

Ability to edit folder settings of local server

When we create an app engine local dev server we need to define a few libraries (work directory, location of appengine-web.xml, etc). Once the server is created, currently there is no way to change/view these settings (apart from possibly digging into config files and manually change them). It would be better to e.g. add them to the editor that is opened when the user right clicks on the server (in the Servers view) and selects 'Open' option.

Provide eclipse settings

for easy import of project

Add rule to ensure we don't link to commons collections 3.2.1

http://www.geekinasuit.com/2016/03/apache-commons-collections-321.html

Verify whether debug and admin port is available when running launching dev app server in debug mode

The code in com.google.cloud.tools.eclipse.appengine.localserver.server.CloudSdkServerBehaviour.canStart(String) checks only for the API port being available, but the server requires an admin port and in debug mode a debug port to be available. This method is called when the UI refreshes and deiced whether to enable/disable the launch buttons in the Servers view.

Although it'd be more explicit for the user if the ports are not available, then this could be displayed to the user either via a tooltip on the disabled buttons or an error dialog when the user clicks on the buttons.

Pick a package name

Before we get any further down this road, let's pick a package name we can stick to. Right now we have

com.google.gcp.eclipse

This may need to change to

com.google.cloud.tools.eclipse

or something similar.

The sooner we make this change (or decide to stick to what we have) the less churn in our repo.

Editing an existing runtime environment should have appropriate title

The dialog which is shown when the user wants to edit the runtime environment of an app engine local dev server has the title 'New App Engine Runtime', however it would be better to show 'Edit App Engine Runtime'. To open the dialog:

• open the Server view
• right click on the dev server instance
• select Open from the menu
• click on the link 'Runtime Environment'

Package naming

Figure out whether we're going to rename to com.google.cloud.tools.eclipse and if so, do it.