When working with Google Cloud Endpoints in a appengine project (eclipse based), some files that describe the api are automatically generated every time the endpoint is edited and for every version.
The files are *-v1.api, *-v1-rest.discovery and *-v1-rpc.discovery (the version number may change) and are placed in WEB-INF.
¿Should these files be committed to source control?
My impression is that if the files are automatically generated, they will always be available and there is no need to track them.
Even if I add more versions of the endpoint in the future, I need to keep all those versions for backwards compatibility so all .api and .discovery files will also be generated for all the versions.
Personally, I don't version control (or even worry about backing up) any generated files. I only worry about source and published binaries. And in theory you don't need the binary either because you should be able to recreate the binary from those source files.
Related
Does anyone know how to restore previous versions of files/directories that have been accidentally overwritten (copied over) in Dropbox? I'm happy to restore the entire directories from the previous day. I'm pretty desperate.
Thanks in advance.
Dropbox does offer an API you can use for listing and restoring versions of files, among other operations. You can find everything you need to get started with the Dropbox API, including documentation, tutorials, and SDKs here:
https://www.dropbox.com/developers
Specifically, to list files, use:
https://www.dropbox.com/developers/documentation/http/documentation#files-list_folder
https://www.dropbox.com/developers/documentation/http/documentation#files-list_folder-continue
And to list the different versions of a file, you would use:
https://www.dropbox.com/developers/documentation/http/documentation#files-list_revisions
And to restore a file to a particular version:
https://www.dropbox.com/developers/documentation/http/documentation#files-restore
Those are links to the documentation for the HTTPS endpoints themselves, but we recommend using one of the official SDKs if possible:
https://www.dropbox.com/developers/documentation
Those have corresponding native methods for the HTTPS endpoints.
Our internal Nexus repository has an artifact that we wish we never published, but unfortunately we did. And various environments installed it.
I'd like to delete it from the repository so that nobody downloads the erroneous release again, but for the people who already downloaded & installed that artifact, it seems a bit deceptive to pretend the release never happened. Is there a way to "archive" or "disable" an artifact so that it still is preserved somewhere for analysis or archeological purposes, but won't be installed by someone pulling artifacts for installation?
There isn't a feature in NXRM for disabling access to individual artifacts. This is a bit hacky but you could achieve it by
Creating a new hosted repository (either raw format or the same
format that you are currently using)
Marking that repository as "offline"
Moving the artifact to the archived repository.
Step 3 is the problematic part: If you are an NXRM PRO user on a recent version there are REST calls you can use for moving components. See here for more details https://help.sonatype.com/repomanager3/staging#Staging-RESTEndpoints
If you are an OSS user you will likely have to republish the same artifact to the archive repository and then delete it from the original repository.
(Note the above assumes you are using NXRM3 - if you are using NXRM2 take a look at https://blog.sonatype.com/2010/04/nexus-tip-moving-artifacts-between-nexus-repositories/)
I'm trying to setup Cloud Debugging for a Python App Engine module without success. See this question for the specific issue I am having.
I am wondering if the reason for my issue is the locations of the source files in my repository.
My source files are (for various reasons) in rather idiosyncratic locations and I have a "build" step that copies the files into into a staging directory where everything is laid out as app engine expects. It also generates some files (including the app.yaml) based on configuration settings.
I then run appcfg.py update from this staging directory.
Given all this moving around of files, I am wondering how the Cloud Debugger can identify which source file in the module I uploaded corresponds to which file in the repository. Is it designed to look in a specific locations (which will explain my problem), or is it somehow more robust than that?
I don't think the issue is related to location of source files in the repository.
The Python Cloud Debugger loops through all the loaded modules and tries to find the best match. The actual location of the module only matters if there are multiple modules with the same name. In this case, the debugger will try to find the best match given the relative path of the files in the repository. You can see the implementation here.
I've slightly "abused" the front-end "version" concept in App Engine (java), to implement modules before they were introduced. I have a configuration consisting of: module1-dot-myapp.appspot.com, module2-dot-myapp.appspot.com, module3-dot-myapp.appspot.com, etc., based on the version concept (more commonly used with numbers: 1-dot-myapp, etc.).
Specifically, the code in all versions is identical, but each is practically used for different purposes. This separation allows different clients to use different api versions, separate deployment schedule, staging versions, logs separation, etc.
My question is, under theses conditions, what is the best way to convert my application to "real" modules? such that "module1" is an actual module (still mapped to the same url - module1-dot-appspot.com)?
Note: my answer comes from a somehow similar exercise but in the python GAE runtime, there is likely aditional Java-specific stuff to look at as well.
First things to look at (possible show stoppers) are the app-level configs - those will need to be merged in from your different old app versions (if they exist) and will be shared by all your modules (or directed to the default module only), so they might not work as before, best to revisit the latest documentation on these configs:
dispatch file
queue
cron
DB indexes
Note: in multi-module python apps these configs might not be updated automatically at app upload, each of them may need to be uploaded explicitly, using the respective app configuration utility options.
The separate deployment schedule is almost free (each module can be deployed independently). But there may be some impact due to the app-level configs (multiple CLI invocations instead of a single one, for example)
The logs separation comes for free.
The staging story might need to be revisited, depending on what exactly you mean by that.
Other than that - you'd bring the different old versions of your app in separate module sub-directories in your new app. Check if your version control system supports this easier. The old app config file(s) would need to be "translated" into the respective module's config file(s) and some of the info would go into the new app's top dir config file.
The module URL routing should allow transparent URL mapping, but note that the URLs will actually be <module>-dot-<appname>.appspot.com and the only way to get exactly the same URLs would be to delete all older app versions before deploying the new one (due to conflicting URLs: <module>-dot-<appname> vs <appversion>-dot-<appname>, not sure if you'll get the old or the new code serving or if it's even possible to deploy the new code without error). You could use a new appname at first, just to get all ducks lined up before the switchover (possibly a new staging story you might consider going forward).
You might find helpful complementing URL routing with a dispatch file if you didn't have one before.
Finally, if you have identical files shared across modules you may consider a single per-app copy of the file, symlinked into the respective modules, if that's easier or makes sense from your source code management prospective.
I have created a GWT project which is successfully using an external jar file (see GWT - Using external jars / Java Projects by Lars Vogel and Adding external jar in GWT).
When I use a library file like this, what happens when I compile the project and upload it to AppEngine? Does the jar file get uploaded as it is, or does it get compiled into something else first? And if the former, is it at any security risk of being downloaded without my control?
Let's drop the "google-app-engine" part, it doesn't matter here. You use the library in GWT, on client side. App Engine is server side, with no direct connection to GWT (but due to the volume restrictions it is quite useful to utilize some client side execution like GWT).
Everything you use in GWT will be compiled to JavaScript, transferred to the client and executed there. Obviously you have no control over the result and what the client does with it.
But it will be next to unreadable. Plus the client does not get the JAR per se and he does not get everything that is inside the JAR.
So what really matters is if the library's license allows this and if there are secrets in the library code that are only intended to be used on server side.
Actually, his's answer is not quite correct. The "google-app-engine"-part matters a lot here. Technically, GWT compiles and obfuscates all of the Java code it needs. And it strips out everything that it doesn't need. So, from the JavaScript generated by GWT, it should indeed be quite impossible to reconstruct or maybe even recognize the library. But it turns out that if you use the Eclipse plugin to deploy your app, appcfg uploads all sorts of random stuff to the AppEngine servers, sometimes including the entire Java source of the project (client side code included).
To see what exactly it uploads when you do a deploy, check in your system's temp-directory while the upload is running. You will find an AppEngine staging directory there that contains everything to be sent.
For suggestions for ways around this, you can refer to the answers to a question that I asked earlier: Removing unwanted uploads from AppEngine deployment
What I haven't checked is whether all the unwanted uploaded files end up in directories that are actually directly accessible from the internet.