Turns out I needed the JAVA_TOOL_OPTIONS environment variable set to -Dfile.encoding=UTF8 to get the release build working. Closure compiler doesn't seem to like files that are not UTF-8.
It seemed strange to me that an environment variable was necessary to work around the issue, so I fixed the problem: The compiler will now always generate JS as UTF-8. -- Josh Tynjala Bowler Hat LLC <https://bowlerhat.dev> On Tue, Jul 16, 2019 at 1:01 PM Josh Tynjala <[email protected]> wrote: > I made some tweaks to the royale-maven-plugin to make it properly use > external-library-path (and js-external-library-path). Now, I can > successfully create a debug build of TourDeJewel with Maven. > > However, it looks like App.js in the release build is empty except for the > source mapping URL. I'm not sure what's going on there. Maybe I'm running > the wrong command to have it also produce a release build. > > -- > Josh Tynjala > Bowler Hat LLC <https://bowlerhat.dev> > > > On Tue, Jul 16, 2019 at 9:47 AM Josh Tynjala <[email protected]> > wrote: > >> Thanks. I'm investigating. >> >> I've figured out that the Maven build is still using library-path (or >> js-library-path) instead of external-library-path (or >> js-external-library-path) when building the framework SWCs. >> >> If I run "mvn clean install" in frameworks/projects/Jewel, I can see that >> a target/compile-js-config.xml file is created, and it's using >> js-library-path for framework SWCs. I'm still figuring out where this >> config file is coming from and how to change it. >> >> -- >> Josh Tynjala >> Bowler Hat LLC <https://bowlerhat.dev> >> >> >> On Tue, Jul 16, 2019 at 9:00 AM Piotr Zarzycki <[email protected]> >> wrote: >> >>> Josh, >>> >>> It looks like something is happened actually. Latest build on server >>> failed, but was able to build all examples and TourDeJewel is not running >>> [1] >>> >>> [1] >>> >>> https://builds.apache.org/job/Royale-asjs/1956/artifact/examples/royale/TourDeJewel/target/javascript/bin/js-debug/index.html >>> >>> Thanks, >>> Piotr >>> >>> wt., 16 lip 2019 o 17:58 Harbs <[email protected]> napisał(a): >>> >>> > These warnings look new: >>> > >>> > Jul 16, 2019 6:55:16 PM com.google.javascript.jscomp.LoggerErrorManager >>> > println >>> > WARNING: externs/dialogPolyfill.js:15: WARNING - accessing name >>> > dialogPolyfill in externs has no effect. Perhaps you forgot to add a >>> var >>> > keyword? >>> > dialogPolyfill = function() { >>> > ^^^^^^^^^^^^^^ >>> > >>> > Jul 16, 2019 6:55:16 PM com.google.javascript.jscomp.LoggerErrorManager >>> > println >>> > WARNING: externs/dialogPolyfill.js:15: WARNING - variable >>> dialogPolyfill >>> > is undeclared >>> > dialogPolyfill = function() { >>> > ^^^^^^^^^^^^^^ >>> > >>> > Jul 16, 2019 6:55:16 PM com.google.javascript.jscomp.LoggerErrorManager >>> > println >>> > WARNING: externs/dialogPolyfill.js:23: WARNING - name dialogPolyfill is >>> > not defined in the externs. >>> > dialogPolyfill.registerDialog = function(dialog) { >>> > ^^^^^^^^^^^^^^ >>> > >>> > Jul 16, 2019 6:55:16 PM com.google.javascript.jscomp.LoggerErrorManager >>> > println >>> > WARNING: externs/hljs.js:19: WARNING - accessing name hljs in externs >>> has >>> > no effect. Perhaps you forgot to add a var keyword? >>> > hljs = function() { >>> > ^^^^ >>> > >>> > Jul 16, 2019 6:55:16 PM com.google.javascript.jscomp.LoggerErrorManager >>> > println >>> > WARNING: externs/hljs.js:19: WARNING - variable hljs is undeclared >>> > hljs = function() { >>> > ^^^^ >>> > >>> > Jul 16, 2019 6:55:16 PM com.google.javascript.jscomp.LoggerErrorManager >>> > println >>> > WARNING: externs/hljs.js:27: WARNING - name hljs is not defined in the >>> > externs. >>> > hljs.highlightBlock = function(block) { >>> > ^^^^ >>> > >>> > Any thoughts on this? >>> > >>> > > On Jul 15, 2019, at 10:32 PM, Josh Tynjala < >>> [email protected]> >>> > wrote: >>> > > >>> > > Hey folks, >>> > > >>> > > I just pushed some commits to royale-compiler and royale-asjs, and I >>> > wanted >>> > > to add a little explanation, and some possible troubleshooting >>> advice if >>> > > anything seems to have broken in your apps. >>> > > >>> > > My work over the last week has been to fix an issue related to >>> specifying >>> > > dependencies when compiling libraries for JS. As you probably know, >>> the >>> > > compiler supports two options for adding libraries as dependencies, >>> > > library-path and external-library-path. The library-path compiler >>> option >>> > > basically says "include all classes that I use from this SWC in the >>> final >>> > > output". It's typically what you use when compiling an app that uses >>> a >>> > > library. The external-library-path compiler option basically says >>> "if I >>> > use >>> > > anything from this SWC, check that I'm using the types correctly, but >>> > don't >>> > > include any of classes from this SWC in the final output". >>> > > >>> > > If you're compiling an app, you typically use library-path for >>> > everything. >>> > > You use external-library-path only for dependencies like >>> > > playerglobal.swc/airglobal.swc in Flash or typedef SWCs in JS. >>> Basically, >>> > > for an app project, external-library-path is for classes that are >>> > provided >>> > > natively by the Flash runtime or a web browser, like Chrome or >>> Firefox. >>> > > >>> > > When compiling libraries, external-library-path is also used to >>> prevent >>> > the >>> > > compiler from creating a "fat" library that stuffs in all of the >>> > > dependencies. Let's say that you have a library, A.swc. It provides >>> some >>> > > core functionality that is needed by both B.swc and C.swc. When we >>> > compile >>> > > B.swc and C.swc, we don't want the classes from A.swc duplicated in >>> both >>> > of >>> > > them. So we add A.swc to the external-library-path when compiling >>> B.swc >>> > or >>> > > C.swc. Then, if you use those SWCs when compiling an app, you need >>> to add >>> > > A.swc, B.swc, and C.swc to the library-path. >>> > > >>> > > To put that in Royale terms, A.swc is something like LanguageJS.swc >>> or >>> > > CoreJS.swc. They're some of our lowest-level SWCs in the framework. >>> B.swc >>> > > and C.swc are more like BasicJS.swc or JewelJS.swc, and they tend to >>> > share >>> > > multiple classes from the lower-level stuff. >>> > > >>> > > Up until now, library-path and external-library-path were a little >>> quirky >>> > > when compiling to JS. It was related to the goog.provide() and >>> > > goog.require() calls that you might have seen in the generated JS. >>> These >>> > > are from the module system that we use in Royale. The compiler didn't >>> > know >>> > > how to differentiate between classes that had goog.provide() and >>> classes >>> > > that were typedefs for JS libraries. It treated everything on the >>> > > external-library-path as a typedef, and this led to missing >>> > goog.require() >>> > > calls in the generated JS. To work around this, when we specified >>> > > dependencies in our framework SWCs, we used library-path to ensure >>> that >>> > > goog.require() would be used. >>> > > >>> > > This workaround of using library-path led to "fat" SWCs that >>> contained >>> > all >>> > > of their dependencies. Low-level classes in SWCs like CoreJS were >>> > > duplicated in higher-level SWCs. This led to the compiler getting >>> > confused >>> > > about exactly where a class was defined. >>> > > >>> > > This has resulted in some minor issues here and there, but nothing >>> too >>> > > major until recently. However, Harbs noticed the other day that it >>> caused >>> > > the compiler to copy extra default CSS into apps from SWCs that you >>> may >>> > not >>> > > have been using. So, you might build an app with the Basic >>> components, >>> > but >>> > > you'd get extra CSS from Jewel or MaterialDesignLite. This could >>> mess up >>> > > your app's styling pretty dramatically. >>> > > >>> > > I updated the compiler to better detect when a class needs >>> goog.require() >>> > > and when it's a typedef. If that class comes from a SWC, the compiler >>> > knows >>> > > to check for an included file like, js/out/com/example/MyClass.js. >>> If the >>> > > generated JS is there, goog.require() is necessary. If it's missing, >>> it's >>> > > treated as a typedef class instead. If the class is an .as source >>> file >>> > > instead, the compiler looks for the @externs asdoc tag to determine >>> if >>> > it's >>> > > a typedef class (and everything else needs goog.require() instead). >>> > > >>> > > By the way, if we ever support other module systems, it shouldn't be >>> too >>> > > difficult to extend this code to detect different SWC layouts for >>> each >>> > > module system. >>> > > >>> > > If your project is an app, this change should not cause any problems. >>> > > You're probably using library-path and external-library-path >>> correctly. >>> > > >>> > > If you have a project that is a library, you should check your >>> compiler >>> > > options to see if you are using library-path and >>> external-library-path >>> > > correctly. If your library depends on another library, you probably >>> > should >>> > > be using external-library-path because you don't want a "fat" SWC. In >>> > other >>> > > words, if you're using library-path in a library project, you >>> probably >>> > need >>> > > to change that to external-library-path. >>> > > >>> > > If you have any custom typedef SWCs, you may want to recompile them. >>> At >>> > one >>> > > point, the compiler had a bug where classes in typedef SWCs were >>> being >>> > > incorrectly added to the "js/out" folder in the SWC, but that was >>> > > incorrect. They should have been placed in an "externs" folder >>> instead. >>> > The >>> > > compiler handles this correctly now, but old typedef SWCs may look >>> like >>> > > goog.require() SWCs instead. To be sure, you can open a SWC file in >>> any >>> > > program that can read ZIP files, and you'll see the internal folder >>> > > structure. If a typedef SWC has a "js/out" folder, it's not going to >>> work >>> > > properly. >>> > > >>> > > If you're working directly out of the royale-compiler and >>> royale-asjs Git >>> > > repos, be sure to update and rebuild them both. The nightly builds >>> should >>> > > be updated shortly. >>> > > >>> > > When you build any apps, be sure to clean first, just to be sure >>> that you >>> > > have the latest JS files from the SWCs. >>> > > >>> > > If you run into any other problems with these changes, please let me >>> > know. >>> > > I'll get them fixed right away! >>> > > >>> > > -- >>> > > Josh Tynjala >>> > > Bowler Hat LLC <https://bowlerhat.dev> >>> > >>> > >>> >>> -- >>> >>> Piotr Zarzycki >>> >>> Patreon: *https://www.patreon.com/piotrzarzycki >>> <https://www.patreon.com/piotrzarzycki>* >>> >>
