Compile a Java application into a single JavaScript file?

[Michael Zhou]

I have used GWT to compile a Java application (Google's Closure Compiler) into a GWT application.

Currently, GWT outputs a .cache.js file and a .nocache.js file. I wonder if it's possible to output a single .js file instead of two?

We might switch to J2CL when it's ready, but just in case it's possible to do so with GWT 2.8.

[Thomas Broyer]

Not sure what you're talking about exactly, but at runtime only one file is loaded.

Is the other file named devmode.nocache.js maybe?

[Greg]

You could use Single Script Linker instead of default Cross Site IFrame Linker by adding this into your module.gwt.xml:

<collapse-all-properties/>

<add-linker name="sso"/>

You have to collapse all properties because sso linker doesn't generate permutation selection script. After compilation you should get single js file which contains all the logic for different browsers / languages etc. Alternatively you could explicitly specify properties but it would mean you would get js file for single browser / language.

On Sunday, December 13, 2015 at 2:58:21 AM UTC+1, Michael Zhou wrote:

[Thomas Broyer]

On Monday, December 14, 2015 at 9:13:56 AM UTC+1, Greg wrote:

You could use Single Script Linker instead of default Cross Site IFrame Linker

He did it already.

[Michael Zhou]

Well there's a <module>.nocache.js and an <md5>.cache.js file. Ideally I want to have a single .js file that I can load from any .html file.

[Thomas Broyer]

On Saturday, December 19, 2015 at 5:09:23 PM UTC+1, Michael Zhou wrote:

Well there's a <module>.nocache.js and an <md5>.cache.js file. Ideally I want to have a single .js file that I can load from any .html file.

But when I go to https://closure-compiler-debugger.appspot.com/gwt_debugger.html only the <module>.nocache.js is loaded, so it's already working as intended.

Not sure why a <md5>.cache.js is generated, but apparently it can be ignored.

[Michael Zhou]

That site runs on a GWT app built from Google's internal Bazel BUILD rules, not from the open-source Maven pom-gwt.xml...

[Thomas Broyer]

Ah, OK.

The solution is a custom linker then; I don't think there's any built-in linker that would do that.

Use the CrossSiteIframeLinker as a base and customize from there; see shouldIncludeBootstrapInPrimaryFragment. Apparently it shouldn't be much work. IIUC, you'd then get a <md5>.cache.js that can be loaded directly. The generated compilation-mappings.txt would tell you the name of that file. AFAIK that's what Google uses (known as SSSS == Server-Side Selection Script), except several permutations are generated and (based on the compilation-mappings.txt) the right <md5>.cache.js is selected on the server side depending on the user.agent making the request (and the locale, from the current request or the logged-in user's profile). If you have a single permutation, then things are a bit easier ;-)

[Kirill Prazdnikov]

Is there a possibility to generate a single script (not a few perms bundled into a one JS) will be added soon ?

Today if I make a one perm, I`ll see a blank screen for different browser.

Is there and reasonable point of having different perms now days (assuming we use the latest Chrome and FF only) ?

As far as I know, modern FF can run Chrome permutation without issues ...

Which file I can expect for differences between perms ?

Is there an option to resolve that differences dynamically via virtual calls?

Thanks

[Michael Zhou]

Thanks Greg, 

<add-linker name="sso"/>

did the trick.

[Kirill Prazdnikov]

<add-linker name="sso"/>

I tried that and this is great. Now I have the only script file and this is not a string like with the xsf linker, this is a normal JS file.

More, I do not need to collapse all perms since I use the only default one for all browsers. It does all I need.

However I have to switch to xsf when I want to start the SDM

[Paul Stockley]

Just define another gwt.xml file for your app that points to the same entry point but uses the sso linker and use this for debugging,