Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Apply auto-recompile to all codeserver compilations #9437

Open
ibaca opened this issue Oct 1, 2016 · 4 comments
Open

Apply auto-recompile to all codeserver compilations #9437

ibaca opened this issue Oct 1, 2016 · 4 comments

Comments

@ibaca
Copy link
Contributor

ibaca commented Oct 1, 2016

Currently only the codeserver first compilation or the launcherDir output uses the LauncherDir.generateStubNocacheJs (i.e. the app.nocache.js that recompile on reload). Is this some kind of limitation? Is it possible to use the auto-recompile.nocache.js for all Recompilations?

This is specially useful to get rid of devmode. Currently if you have a client only or a CORS enabled app, and you put your index.html inside your app module public folder, you can use the codeserver to bootstrap your app. The unique actual disadvantage compared to devmode is that devmode uses the auto-recompile.nocache.js but codeserver doesn't.

@tbroyer
Copy link
Member

tbroyer commented Oct 1, 2016

I think we should aim at replacing c.g.g.dev.DevMode with a "devserver" (possibly baked into CodeServer, but not necessarily) similar to Webpack:

  • serve static content from the launcherDir (don't assume a Java web app, only static content),
  • add possibility to configure paths (including /) to be reverse-proxied, possibly from the command-line like devd (so we don't need a config file; add notation to tell whether to rewrite the host header or not)
  • intercept all requests to *.nocache.js (possibly only <modulename>/<modulename>.nocache.js, maybe only for "known" modules) to trigger a recompile (i.e. serve the stub, without necessarily having to write it to disk in any public directory)

That way:

  • you can proxy all requests to external/shared servers, without the need to deploy the stub nocache.js to those servers
  • you wouldn't have the stub nocache.js written to your launcherDir, therefore not polluting your target directory, if you already compiled your app (as can be the case with Maven or Gradle) or your target directory is also your source directory (e.g. for standalone apps, so you don't even need to put your static resources into the module's "public path")
  • you can easily use embedded servers (or whatever) for your webapp that doesn't serve resources from a directory (CodeServer with -launcherDir wouldn't work then, because you would have no way to serve the stub nocache.js)

@tbroyer
Copy link
Member

tbroyer commented Oct 23, 2016

Proof-of-concept devserver at https://github.com/tbroyer/gwt-devserver

@branflake2267
Copy link
Contributor

Whoa, I like the sounds of it.

@branflake2267
Copy link
Contributor

By the way, there is another way around funky web app configurations. That's use the Compiler with incremental, to compile into the output directory with only one permutation for testing quickly. Then it doesn't matter if it's ssl, or has odd directory. The only issue here, is the web servlet container, or hosting container has to know about the new resources pushed into it, and refresh.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants