How can I share files (HTML templates) between App Engine modules? - google-app-engine

I am using the Go runtime of Google App Engine and have two modules. I would like to share HTML templates between them but don't the best way.
My modules are organised as below:
src/github.com/myproject/moduleone/app.yaml
src/github.com/myproject/moduleone/templates/base.html
src/github.com/myproject/moduleone/templates/homeone.html
src/github.com/myproject/moduletwo/app.yaml
src/github.com/myproject/moduletwo/templates/base.html
src/github.com/myproject/moduletwo/templates/hometwo.html
In my situation base.html is the same for moduleone and moduletwo. How can I share it between both modules without having to duplicate the file as is done now?
I would like to put base.html in a directory called src/github.com/myproject/templates but I believe neither moduleone or moduletwo would be able to access the file as it's not in the same or child directory of the module app.yaml files. Is my only option to symlink the base.html file between each module's template directory?

GAE regards each module as a standalone application (each will run in its own GAE instance). No uploadable artifacts are shared at GAE level between the modules, each such artifact needs to be separately uploaded in each module using it.
While other approaches are technically possible (as other mentioned) symlinking the files is IMHO the simplest solution to avoid code duplication in your own repo.

You could copy the templates to each module as part of a build step and gitignore the copied files.

Related

Where to put Thorntail Swarm Configuration (project-defaults.yml) within a multi module Gradle project?

I'm trying to configure the Swarm AS based on Thorntail 2.5.0.Final with a project-defaults.yml within a multi-module Gradle project. Unfortunately the configuration file doesn't get picked up.
Where do I have to put the project-defaults.yml file so it's registered by Thorntail?
Currently the situation looks like this:
I think the sub module resources folder is not correct, because this configuration file should configure the whole AS, right?
The file belongs to src/main/resources. It seems you already have one there -- are the two different?
If you have a multi-module project, generally there should be one module that builds the uberjar, and that module should have src/main/resources/project-defaults.yml.

How can I read files outside src?

I understand that in react you cannot import files outside src folder.
But what is the reason for it exactly and can I disable it?
In my project react web app is only part of the whole thing, and different parts share some files (configs, build output), so folder structure looks like this
ProjectRoot/
config
build-output/
Part1/
Part2/
WebApp/
src/
...
Sure, you can copy files or create symlinks, but that's duplication and inconvenient.
This is a restriction of Create React App only.
This tool exists to get new users up and running with the react framework as fast as possible by abstracting away the tooling. The part of tooling that is limiting you in this instance is their webpack configuration, which is preset to only look for javascript files in your src directory.
That explains the why? but to answer the other half of your question:
how can I disable it?
Is that you would need to eject from Create React App and then modify your webpack config to allow it to search directories other than src/
First - this has nothing to do with react itself.
If you refer to importing javascript modules (for now using module loaders like systemjs, require, etc.) then the answer is:
It depends what directory is being served by web server. If you have set up your web server to serve WebApp/src folder only - then no, browser will not be able to get access to the files outside and so module loaders. If you will serve all ProjectRoot directory - then yes, you can.
If you prepare your web application for deployment using some sort of bundlers (webpack, browserify) - it depends on how you will configure them and instruct to include the required files in the resulting bundle.

Do AppEngine-Go modules have to share the same code base

The canonical example given for appengine-go module uploads implies that all modules within a given app must share the same codebase.
e.g. appcfg update app.yaml mobile-frontend.yaml my-module.yaml
In this case, all Go files in the app root directory are processed identically for each module (and therefore share the same code).
Is there any way to specify a separate root directory for each module e.g. as a sub-directory of the default app root?
TIA
As a new SO user, I was restricted by the 8-hour limit for answering my own question. Therefore I posted it initially as a comment.
So here is the link in question for anyone who runs into this problem:
https://groups.google.com/d/msg/google-appengine-go/T90jtkZ83s4/MizIcnjH4QIJ
As an aside, the new modules paradigm is vital for GAE projects. Not only does it allow for different code bases for each module but also different runtimes!!!
This means that, theoretically at least, you can leverage the best features of each language within the same app. Nice!
Finally got my app working in development and on App Engine. Thanks. To summarize the thread:
My app directory looks like this:
$ ls *
README.md dispatch.yaml
frontend:
app.yaml index.html server.go
images:
images.yaml server.go
Then to run in development:
$ goapp serve dispatch.yaml */*.yaml
and to deploy:
$ appcfg.py update_dispatch .
$ goapp deploy */*.yaml
Source code.

GAE App.yaml - separate directories for src and build static files

Is it possible to optionally override a static files directory in the Google App Engine app.yaml file if another directory exists? I have a source directory (unminified) and a build directory (minified and concatenated). I want Google App Engine to automatically use the build directory instead of the src directory, if it exists. That way I can dev using the src directory, then create a build and deploy it. Then, if I delete the build directory, GAE goes back to serving my static files from the src directory.
The reason I need to do this is because I am building an application with Backbone.js & Require.js as modules. I need to be able to optimize my code and deploy without changing my app.yaml file every time.
I'm pretty happy with my current system where my framework uses different paths in the templates to the source javascript files. Then at startup, through a combination of checking os.environ and get_application_id() I automatically detect whether I'm running locally on dev_appserver, or under my test appid or production appid on GAE.
And on to the next step, you most likely want to cache your minified JS aggressively, in which case you'd be unable to force clients to update a new version. The typical workaround is to append a hash or date string to the minified js filename whenever it's updated. This is something you'll also need to do in your framework/templating layer instead of app.yaml.
I would do this at the template layer - when you go to render the template that includes links to your assets, check to see if the minified version exists. If it does, link to that - otherwise, link to the unminified version.
This also helps if you accidentally deploy without creating a build - you'll just be serving unoptimized assets.

Using workspace projects with AppEngine

I'm trying to use a library project with my Google AppEngine project as a project on build path.
Is there a way to get that included in the AppEngine project without having to copy the entire source or make a jar ?
I only use a small portion of the library so it seems like overkill to copy the whole jar and a lot of work to find the dependencies within the source to get only the parts I'm using.
I added an ant project builder that copies the class files from the dependent project.
The ant file resides in the gae project and copies the class files from the referenced project.
Here's the ant:
<?xml version="1.0" encoding="UTF-8"?>
<project name="CommonsCopy" default="copy" basedir=".">
<target name="copy">
<copy todir="war/WEB-INF/classes">
<fileset dir="../Commons/bin" includes="**/*.class">
</fileset>
</copy>
</target>
</project>
I named it 'CommonsCopyBuilder.xml' as it copies code from a commons project.
This will copy the files to the appropriate location just before running the project.
You are not going to like this answer, but No.
In order to include the library as a dependency in the project once deployed the required library must be found in your WEB-INF/lib directory as a jar. This is going to require you to you to create a jar based on the library you want to use. The other option is to do just as you said pull the dependent source into your project and use it from there.
During development you can make the library project a dependency of your app engine project by doing the following:
Under Project->Properties->Java Build Path->Projects Tab
select the "Add.." button to add a subproject to your build.
Note: This will not address the the running in a production environment.
I managed to do this by creating the libary project is a "Web Fragment Project" and adding it to the "Deployment Assembly" in the project properties of the app engine project.
However, the app engine project does not seem to work with non-trivial dependency structures. In my case, I had two app engine modules within an EAR, both depending on the libary project. However, the Google plugin only bundled the library project with one of the modules, never with both at the same time despite identical configurations. Obviously a bug.
My work-around was to add a linked source folder to the app engine projects, pointing to the source folder of the library project. Ugly, but it does the job.

Resources