Add support for YAML files for App Engine content block#3186
Add support for YAML files for App Engine content block#3186briandealwis merged 10 commits intomasterfrom
Conversation
For example: project was using app.yaml, but appengine-web.xml appears
Codecov Report
@@ Coverage Diff @@
## master #3186 +/- ##
============================================
+ Coverage 69.75% 70.02% +0.26%
- Complexity 2931 2963 +32
============================================
Files 372 373 +1
Lines 13422 13511 +89
Branches 1611 1622 +11
============================================
+ Hits 9363 9461 +98
+ Misses 3377 3373 -4
+ Partials 682 677 -5
Continue to review full report at Codecov.
|
| } | ||
|
|
||
| /** | ||
| * Test that creating that a newly-created {@code appengine-web.xml} "overrides" the previous |
There was a problem hiding this comment.
"... creating a newly ..."
| public void setUp() { | ||
| // Many of ResourceManager's methods are final; we check getImage() methods | ||
| // by verifying that create() is called | ||
| doReturn(null).when(resourceManager).create(any(DeviceResourceDescriptor.class)); |
There was a problem hiding this comment.
AFAIK, a mock will return null for non-mocked methods by default, so I don't get why this is needed.
There was a problem hiding this comment.
hmm, I'm sure there was a reason! But it doesn't seem to fail now…
| @@ -105,8 +105,8 @@ public void testAppEngineStandardProjectElementCreate_initial() throws AppEngine | |||
| @Test | |||
| public void testAppEngineStandardProjectElementCreate_staggered() throws AppEngineException { | |||
There was a problem hiding this comment.
The method name contains "Standard". There are other methods having that too.
| * Create an App Engine configuration file in the appropriate location for the project. | ||
| * | ||
| * @param project the hosting project | ||
| * @param relativePath the file name |
There was a problem hiding this comment.
"relative path to the file"?
| public static IFile createConfigurationFile( | ||
| IProject project, | ||
| IPath relativePath, | ||
| InputStream contents, |
There was a problem hiding this comment.
I was going to say this could just be String, but then WebProjectUtil.createFileInWebInf() takes InputStream too. Looking at the callers, they could both accept String, but I don't want to stretch this PR for that. I just think this can just be String, what about you?
There was a problem hiding this comment.
It's modelled directly after IFile's create() / setContent() which takes an InputStream. But I certainly don't see anything wrong with helper methods.
| IFolder appengineFolder = project.getFolder(DEFAULT_CONFIGURATION_FILE_LOCATION); | ||
| if (appengineFolder != null && appengineFolder.exists()) { | ||
| IFile destination = appengineFolder.getFile(relativePath); | ||
| if (destination.exists()) { |
There was a problem hiding this comment.
No need to call exists() twice. This could basically be
IFile destination = project.getFolder(DEFAULT_CONFIGURATION_FILE_LOCATION).getFile(relativePath);There was a problem hiding this comment.
Ditto the above: it can be with mocks.
There was a problem hiding this comment.
getFolder() returning null.
There was a problem hiding this comment.
Okay, that's fair. I still don't get the inconsistency (checking null for getFolder() but not for getFile(), etc.), but this is not a big deal.
There was a problem hiding this comment.
Point taken: I'll add a null check here too.
There was a problem hiding this comment.
You're right the null check shouldn't be necessary and I will instead fix up any tests.
But back to your original question about combining into one chain: we need to split it up as we only create or update the file providing the I think it's time for me to go home: responding to the wrong comment.src/main/appengine exists. If it doesn't exist, then we put it into WEB-INF.
| /** Returns a <em>project:service:version</em> tuple from the App Engine descriptor. */ | ||
| @VisibleForTesting | ||
| static String getVersionTuple(AppEngineDescriptor descriptor) throws AppEngineException { | ||
| static String getVersionTuple(String projectId, String projectVersion, String serviceId) { |
There was a problem hiding this comment.
The order seems weird, given that the tuple will be "project:service:version".
There was a problem hiding this comment.
This method was a hold-over when I maintained both a AppEngineDescriptor and AppYaml instance. I can just pass in the AppEngineProjectElement.
| } | ||
| } else if (Iterables.any( | ||
| projectFiles, file -> file != null && "appengine-web.xml".equals(file.getName()))) { | ||
| } else if (anyMatch(projectFiles, Sets.newHashSet("appengine-web.xml", "app.yaml"))) { |
There was a problem hiding this comment.
Can we reuse AppEngineProjectElement.hasAppEngineDescriptor()?
There was a problem hiding this comment.
Oh yes! I forgot about this.
| private String projectVersion; | ||
| private String serviceId; | ||
|
|
||
| /** Return the App Engine environment type (e.g., standard, flexible). */ |
There was a problem hiding this comment.
Looking at the code, this would be flex for the flexible and null for the standard, wouldn't it?
| /** Return the App Engine environment type (e.g., standard, flexible). */ | ||
| private String environmentType; | ||
|
|
||
| /** Return the App Engine runtime (e.g., java7, java8). */ |
There was a problem hiding this comment.
The comment is not really correct. The values are not compatible between standard and flex, and I think we should clearly explain it. For example, for standard, the values are null and java8, and for flex, the values are java, custom, python27, etc. I haven't checked the actual runtime: value of app.yaml auto-generated from appengine-web.xml where <runtime> is not present (i.e., java7) or it is set to java8, but another point of confusion could be the possibly different values of runtime: and <runtime> after the auto-conversion.
There was a problem hiding this comment.
… and here. I'm currently returning the actual values and leaving the interpretation in getStyledText(). But it's more useful to provide the right interpretation here.
There was a problem hiding this comment.
Verified auto-generated app.yaml from an appengine-web.xml has runtime: java7 or runtime: java8.
| <classpathentry kind="con" path="org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.debug.ui.launcher.StandardVMType/JavaSE-1.7"/> | ||
| <classpathentry kind="con" path="org.eclipse.pde.core.requiredPlugins"/> | ||
| <classpathentry kind="src" path="src/"/> | ||
| <classpathentry kind="src" path="tests"/> |
There was a problem hiding this comment.
Just confirming (and for documentation), this is a cleanup?
There was a problem hiding this comment.
Oops sorry, this shouldn't have been included. Photon now supports scoped classpath entries, and some action occasionally causes the IDE to regenerate the .classpath files.
| IFolder appengineFolder = project.getFolder(DEFAULT_CONFIGURATION_FILE_LOCATION); | ||
| if (appengineFolder != null && appengineFolder.exists()) { | ||
| IFile destination = appengineFolder.getFile(relativePath); | ||
| if (destination.exists()) { |
There was a problem hiding this comment.
Okay, that's fair. I still don't get the inconsistency (checking null for getFolder() but not for getFile(), etc.), but this is not a big deal.
|
We have this |
Adds support for
app.yamland the various App Engine.yamlconfiguration files. This change moves support for resolving App Engine configuration files into a utility class calledAppEngineConfigurationUtil; we were previously lumping these files intoWEB-INF. The idea is that this class can use the project facets and language types to determine the right place for these configuration files.But you'll notice that this
AppEngineConfigurationUtilclass doesn't currently do any of the special logic. I started down the path of adding special logic for App Engine standard vs flexible for determining where these configuration files should be looked up, but giving some of @ludoch's musings about new configuration files I thought it was better to support asrc/main/appengineif present, and figure out the rest later. It checks if there's ansrc/main/appengineand tries to resolve the file there, and otherwise looks in theWEB-INF. This works for our existing projects as AES projects don't havesrc/main/appengineand all files are placed inWEB-INF, and AEF projects were usingsrc/main/appengineanyways. This has a few knock-on effects:.yamlconfiguration files will be found and showed when they are located inWEB-INF: this is unlikely.src/main/appenginewill break on run or deployment since our launch and deployment processes do not currently resolving files from there. This is an unlikely to happen in practice. And such projects can easily be made to work with by mappingsrc/main/appenginetoWEB-INFthe project's Deployment Assembly.We may want to teach our projects to place these App Engine configuration files to an alternative well-known location via the deployment assembly (e.g.,
WEB-INF/appengine)?Fixes #3091
Fixes #3099