Thanks for taking a look at this Josh, I could try that build tomorrow as I do a full rebuild with maven as usual
thanks El mar., 16 jul. 2019 a las 18:47, Josh Tynjala (<[email protected]>) escribió: > 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>* > > > -- Carlos Rovira http://about.me/carlosrovira
