Issues I faced setting up my MIT App Inventor Local Server

[Samuel_Dahunsi]

I’ve been spending some time building on my local App Inventor server setup for my GSoC application, and I just wanted to share that it’s been a really rewarding experience once everything clicked into place.

Running App Inventor locally has made the project feel much more concrete for me. It’s been especially helpful for understanding the full flow, from building the web app, to running the local servers, to thinking about how an actual project would be developed and tested outside the production MIT instance. I’m currently using it to prototype a teacher-facing app idea around classroom project management, and working in a local environment has made that process feel much more realistic and educational.

That said, setup was definitely not completely smooth on my end. A few issues I ran into:

• Ant was picking up the wrong Java version, so I had to separate my setup between Java 11 for ant and Java 17 for the App Engine dev server.

• I hit build failures caused by generated component metadata not appearing when Ant was run under the newer JDK.

• I also ran into a Blockly/Closure compiler path issue because my repo was inside a folder with spaces in its name.

• There was also some confusion from older README instructions around using java_dev_appserver.sh versus newer App Engine tooling.

Once I worked through those, the local setup became much more manageable, and I’m glad I stuck with it. Going through the setup pain honestly gave me a much better understanding of the architecture and developer workflow.

If anyone else is setting up a local App Inventor instance for the first time, I’d be happy to compare notes. It definitely took some debugging, but it’s been worth it.

[Diego]

@Samuel_Dahunsi

Ant was picking up the wrong Java version, so I had to separate my setup between Java 11 for ant and Java 17 for the App Engine dev server.

You may want to try Mise to manage all versions: https://mise.jdx.dev/

Then, in the App Inventor folder, just run:

mise use java@corretto-11

So the project in particular gets the correct version, while you can maintain a different global one. It's much easier to manage different Java, Python, Node, etc., versions using Mise rather than manually.

@Samuel_Dahunsi

I hit build failures caused by generated component metadata not appearing when Ant was run under the newer JDK.

Maybe you could raise a PR to add a warning notice or something for future users? Although in the README it already says Java 11 is needed...

@Samuel_Dahunsi

I also ran into a Blockly/Closure compiler path issue because my repo was inside a folder with spaces in its name.

Yeah, I remember seeing somewhere else this kind of issues. Maybe another PR to add a warning if this is detected?

@Samuel_Dahunsi

There was also some confusion from older README instructions around using java_dev_appserver.sh versus newer App Engine tooling.

I do personally use mise for this. This is what my mise.toml file looks like:

[tools]
java = "corretto-11"
gcloud = { version = "533", os = ["linux", "macos"] }

# a bunch of other commands for building sources, companion, etc.

[tasks.local-server]
description = "Run Local Server"
dir = "appinventor"
run = "java_dev_appserver.sh --port=8888 --address=0.0.0.0 appengine/build/war/"
run_windows = "java_dev_appserver.cmd --port=8888 --address=0.0.0.0 appengine/build/war/"

That way, I can just run:

mise run build
mise run local-server

And I get the server up and running without the unnecessary long java_dev_appserver.sh command...

But I do agree the README is confusing. Again, if you have suggestions for improving, feel free to raise a PR

[Samuel_Dahunsi]

Thanks Diego, this is really helpful.

mise looks like a nice way to make the local setup a lot less painful, especially when juggling different Java versions for different parts of the workflow. I hadn’t used it before, but I can definitely see why it would be cleaner than managing everything manually.

That said, I also agree it still makes sense to improve the default contributor experience in the repo itself, especially for people following the README and using the built-in tooling as-is. Based on the setup issues I ran into, I’ve now gone ahead and raised the relevant issues/PRs around:

• the Blockly/Closure build failing when the source tree path contains spaces

• the confusing/stale parts of the local setup documentation in readme

So I’m treating mise as a very useful workaround/convenience layer, but not necessarily a replacement for improving the repo’s own diagnostics and documentation.

Thanks again for the suggestion and for sharing your mise.toml setup too, that gives me a much better idea of how others are smoothing out the local workflow.