Thanks for the update. I will pull the release modules branch source, build and test again.
One question what compilation options should be used for this test ? Load externs, externs, link report ? Which options should be applied for the main and which option should be used for the module ? >From your mail below I can see that a new option have been added so I need clarity on this before I proceed with this test. On Wed, 12 Jan 2022, 09:04 Alex Harui, <aha...@adobe.com> wrote: > I pushed a ReleaseModules branch in royale-compiler and royale-asjs. > > > > These changes cause the royale-asjs/examples/royale/ModuleExample release > version to work. > > > > The big challenge is that it turned out there is a fair amount of > infrastructure that is not exported/public. The Language utilities, > ROYALE_CLASS_INFO, the superclass_ property, cssData and others are going > to get renamed. And thus renamed differently in the main app vs the module. > > > > That’s why the current compiler’s strategy was to try to copy the renaming > map from the main app to the module, but it didn’t always work. There > seems to be a bug in the Closure Compiler that a set of externs causes the > compiler to mis-handle package-paths. Also, it meant that the module > contained its own copy of most of the infrastructure > > > > The new compiler strategy is a bit more like the old Flex module > strategy. The module tries to not contain a copy of code that already > exists in the main app. Some of the goog/base.js stuff still gets copied > though. Then because we avoid renaming more things, the module can > reference the shared infrastructure in the main app. > > > > The new compiler detects if what is being compiled is a loader of modules > (because it is generating an externs-report) or is a Module and prevents > renaming of Language APIs, modified base.js to not rename the superClass_ > property used for calling super() and a few other things. In addition, I > added a -prevent-rename-object-keys compiler option that works as a > post-processor. It scans the js files being copied into bin/js-debug and > adds quotes around things. > > > > By making these changes, I was able to get the closure compiler to > mis-handle the packages in a more predictable way, so another thing the new > compiler does is post-process the output file to remove the incorrect > package code. The incorrect code would re-init package paths like “org” or > “org.apache.royale”. > > > > Anyway, give it a try and see if it works. Probably we’ll find out there > is more infrastructure that needs to not be renamed, but I think this has a > better chance of working as we aren’t blocked by the compiler outputting > bad code. Many months ago I tried to understand how why the Closure > Compiler output bad code, but ran out of time. > > > > Another difference is that the new compiler strategy doesn’t use custom > overrides of Closure Compiler passes which was fragile and will make it > easier to upgrade to newer versions of Closure Compiler. > > > > HTH, > > -Alex > > > > *From: *Alex Harui <aha...@adobe.com> > *Reply-To: *"users@royale.apache.org" <users@royale.apache.org> > *Date: *Wednesday, January 5, 2022 at 9:53 AM > *To: *"users@royale.apache.org" <users@royale.apache.org> > *Subject: *Re: Compiling Modules (was Re: Load time is very slow) > > > > I probably won’t have time to really dig into this until the weekend. It > is looking like the Closure Compiler gets confused when presented with > externs for the same package tree that the module is generating new classes > for. > > > > -Alex > > > > *From: *Roman Isitua <romanisi...@gmail.com> > *Reply-To: *"users@royale.apache.org" <users@royale.apache.org> > *Date: *Tuesday, January 4, 2022 at 1:57 PM > *To: *"users@royale.apache.org" <users@royale.apache.org> > *Subject: *Re: Compiling Modules (was Re: Load time is very slow) > > > > Okay. I knew I was missing something. > > > > I will test again when the update for load-externs is available. > > > > On Tue, Jan 4, 2022 at 6:02 PM Alex Harui <aha...@adobe.com> wrote: > > Essentially, -externs-report is for the Closure (JS) Compiler. > -link-report and -load-externs (one leading ‘-‘) is for the Royale Compiler > to tell the Royale Compiler what classes to feed to the Closure Compiler. > Both contain the same data (the set of classes used in the main app), just > formatted differently and used differently. > > > > The –externs option for the Closure Compiler then tells the Closure > Compiler not to look for classes in the set of files it is supposed to > minify. > > > > So, you have the right settings for the main app, but for the module, it > should be: > > *-js-compiler-option=--externs extrep.txt; -load-externs linkrep.txt;* > > > > However, even that won’t work today, as the Royale Compiler is not > handling -load-externs on the JS prep for Closure Compiler. I have some > local changes to the compiler that mixes most of it, but am facing issues > with how Closure handles package paths. If that can be resolved, then we > have a good chance of things working. > > > > -Alex > > > > *From: *Roman Isitua <romanisi...@gmail.com> > *Reply-To: *"users@royale.apache.org" <users@royale.apache.org> > *Date: *Tuesday, January 4, 2022 at 12:39 AM > *To: *"users@royale.apache.org" <users@royale.apache.org> > *Subject: *Re: Compiling Modules (was Re: Load time is very slow) > > > > Thanks for the update. > > > > I attempted the following: > > > > 1. In the main application, I use the following setting: > > *-externs-report=extrep.txt; -link-report=linkrep.txt;* > > > > 2. In the module I use the following > > > > *-js-compiler-option=--externs extrep.txt; > -js-compiler-option+=--load-externs linkrep.txt;* > > > > The main application compiles successfully, I get a compilation error with > the module > > > > "--load-externs" is not a valid option > Sample usage: --compilation_level (-O) VAL --externs VAL --js VAL > --js_output_file VAL --warning_level (-W) [QUIET | DEFAULT > | VERBOSE] > Run with --help for all options and details > Internal error: java.lang.NullPointerException > com.google.javascript.jscomp.CommandLineRunner.createOptions(CommandLineRunner.java:1809)org.apache.royale.compiler.utils.JSClosureCompilerWrapper$CompilerOptionsParser.getOptions(JSClosureCompilerWrapper.java:529)org.apache.royale.compiler.utils.JSClosureCompilerWrapper.<init>(JSClosureCompilerWrapper.java:77)org.apache.royale.compiler.internal.codegen.mxml.royale.MXMLRoyalePublisher.publish(MXMLRoyalePublisher.java:395)org.apache.royale.compiler.clients.M > > > > > > > > I don't think I am using this option correctly. > > > > > > > > ..... > > > > On Tue, Jan 4, 2022 at 8:44 AM Alex Harui <aha...@adobe.com> wrote: > > I found some time to investigate. The -externs-report option is mostly > working correctly, but other compiler changes are needed to try to avoid > duplicate code in the module. I might have time to investigate more this > coming weekend. It does appear that if we can correctly reference the > app’s class from the module that it will work. The Closure Compiler let me > compile the module after I externalize and avoid requires on everything in > the main app’s externs report and -js link report, but the references in > the module have collapsed packages which is either incorrect or aliases > need to be created. > > > > However I think this new approach has a better chance of working than > trying to match renaming tables. > > > > -Alex > > > > *From: *Alex Harui <aha...@adobe.com> > *Reply-To: *"users@royale.apache.org" <users@royale.apache.org> > *Date: *Monday, January 3, 2022 at 2:30 PM > *To: *"users@royale.apache.org" <users@royale.apache.org> > *Subject: *Re: Compiling Modules (was Re: Load time is very slow) > > > > The -externs-report option should be similar to the -link-report option. > It takes a filename. The compiler should output the classes used in the JS > compile into that file. To use externs, I think you don’t need to prevent > renaming in the application as long as public variables are exported. I > think you specify -externs-report when compiling the application. > > > > You may also need to output a -link-report from the application as well. > > > > I think you then specify the externs-report file as an -externs for the > -js-compiler-options when compiling the module. And maybe also specify the > -link-report output as a -load-externs in the same way it was used when > compiling Flex modules. The goal for the module is, like Flex, to not have > any classes in the module that exist in the main app. Then it doesn’t > matter about class renaming within the release-mode JS file. > > > > HTH, > > -Alex > > > > *From: *Roman Isitua <romanisi...@gmail.com> > *Reply-To: *"users@royale.apache.org" <users@royale.apache.org> > *Date: *Monday, January 3, 2022 at 12:37 PM > *To: *"users@royale.apache.org" <users@royale.apache.org> > *Subject: *Re: Compiling Modules (was Re: Load time is very slow) > > > > > > I can confirm that classes are being renamed in both files. > > > > I have attempted your suggestion i.e. removing variable maps and property > maps then use > > -externs-report;-export-public-symbols=true;-prevent-rename-public-symbols=true; > > > > > I get the below error > > > > command line Error: configuration variable 'externs-report' expected 1 > argument(s), got 0. > > > > I cannot find any documentation on how to use the -externs-report > argument. What does it do ? and what are the acceptable values ? > > > > Regards, > > > > > > On Sun, Jan 2, 2022 at 9:06 AM Alex Harui <aha...@adobe.com> wrote: > > Hi Roman, > > > > It might be more complicated. The settings are probably doing something > since you reported that the error occurred in the app vs the module > depending on the settings. > > > > I went back and looked at the original module example in > examples/royale/ModuleExample and was surprised there weren’t more compiler > settings. I thought we’d found a way to externalize the main app’s code > for the module. Because if both the app and module have a copy of > SimpleCSSValuesImpl or any other class that both JS files use, there could > be issues as to which one gets loaded (maybe both) and what export aliases > are pointing to. Sounds like changing settings affected whether the > aliases pointed at module code vs app code. > > > > I thought we were using similar settings to what we used for SWF where the > module would not contain a copy of SimpleCSSValuesImpl so it would use the > one loaded by the main app, but I didn’t see those settings. We might need > to make that work because otherwise I think static initializations won’t do > the right thing. Or maybe we’ve figured out that it is simpler just to > write defensive code that doesn’t get broken. But also, if the module has > its own copy of code already loaded by the main app, that’s sort of a waste > of bytes. Maybe there was a minification issue with not having the module > link in classes already linked into the main app. I see an -externs-report > option in the compiler but the example doesn’t seem to use it. > > > > You should be able to scan the JS files and see if a class is in both > module and app and if it is getting renamed. > > > > I don’t know if I will have time to investigate further. The currently > recommended options for modules involving variable maps and property maps > may need to be abandoned in favor of externs and preventing renames. > > > > -Alex > > > > > > *From: *Roman Isitua <romanisi...@gmail.com> > *Reply-To: *"users@royale.apache.org" <users@royale.apache.org> > *Date: *Saturday, January 1, 2022 at 3:02 AM > *To: *"users@royale.apache.org" <users@royale.apache.org> > *Subject: *Re: Compiling Modules (was Re: Load time is very slow) > > > > Alex, thank you for your detailed analysis of the error log. > > > > I agree with you that the best strategy is to prevent renaming of > public/exports used by the module. I have tried different options to > prevent renaming > > It appears none of them stops this. From my observation, it appears that > this default options below > > > > > -export-public-symbols=true;-prevent-rename-public-symbols=true;-prevent-rename-public-instance-accessors=true; > > > > Only seem to affect the main application (main module) but have no effect > on the other modules even though I ensured they were applied in > their respective module pom. I came to this conclusion when I decided to > turn set -prevent-rename-public-symbols=false > > > > I noticed that I got the same error but this time around in the main > module. > > > > Uncaught TypeError: this.rb[(intermediate value).Kd(...)] is not a function > at HN.iI.send (FrontEnd.js:970) > at nI.EH.Ea (FrontEnd.js:880) > at ON.q6 (FrontEnd.js:1815) > at TN.L2 (FrontEnd.js:2034) > at hF.Xf (FrontEnd.js:2063) > at lF.kb (FrontEnd.js:1233) > at lF.Vf (FrontEnd.js:1224) > at cF.O (FrontEnd.js:659) > at cF.M.w (FrontEnd.js:661) > at gQ.mA.M (FrontEnd.js:241) > > > > FrontEnd.js maps to FrontEnd.as in my application and is the entry point > of the application. This confirms that -prevent-rename-public-symbols=false > has > > an effect on the main module but no effect on other modules even though > they were applied in the respective module pom's. > > > > Maybe there are other options I am overlooking. > > > > On Sat, Jan 1, 2022 at 9:31 AM Alex Harui <aha...@adobe.com> wrote: > > In case it helps, the minification (variable renaming) mechanism is > essentially guaranteed to cause problems in modules. The Closure Compiler > basically takes variables, sees if it is worth renaming it, then gives it > the name ‘a’, then ‘b’, and so-on, (it skips a few letters, IIRC), then > moves on to ‘aa’, and ‘ab’, etc. The odds that the compiler will encounter > the same variables in the same order when compiling an app and one or more > modules is close to zero. > > > > I did some work to try to dump the mapping of the renamed variables in the > main app and use that when compiling the modules. It was working for a > while, then some code was added to the framework that started fooling the > Closure Compiler. I spent some time trying to fix the Closure Compiler, > but ran out of time. Meanwhile, Josh was adding more control over renaming > so I moved on to other things. > > > > IMO, the best strategy to take would be to try to control what gets > renamed. All public/exports from the app that are used by the module > should not be renamed. That will definitely make the app and modules > bigger, but unless the Closure Compiler folks become interested in > runtime-loaded modules, it is challenging for the Royale compiler to allow > aggressive renaming. > > > > I think what is going on with the exceptions below is that exporting > doesn’t really prevent renaming. It only sets up an externally-visible > alias to a renamed variable. Especially for static members. So it isn’t > sufficient to export public variables, the code within the module must not > let the Closure Compiler think that the intra-module references can be > renamed, in this case, from SimpleCSSValuesImpl to QI > > > > I don’t know the renaming options we’ve added to the Royale Compiler, so I > don’t know if there is an option to control that. I think there is a way > to convince the Closure Compiler to not rename SimpleCSSValuesImpl because > I’ve seen other class names not get renamed. > > > > HTH, > > -Alex > > > > *From: *Roman Isitua <romanisi...@gmail.com> > *Reply-To: *"users@royale.apache.org" <users@royale.apache.org> > *Date: *Friday, December 31, 2021 at 10:42 AM > *To: *"users@royale.apache.org" <users@royale.apache.org> > *Subject: *Re: Compiling Modules (was Re: Load time is very slow) > > > > I have tested on both. The error log is the same. > > > > I don't understand your second question. Kindly clarify ? > > > > > > I followed strictly the approach used for loading modules here in this > example. > > This is the only method I know for loading modules. If there is another > method please share. > > > > > > > https://royale.apache.org/dividing-an-apache-royale-application-with-modules/ > <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Froyale.apache.org%2Fdividing-an-apache-royale-application-with-modules%2F&data=04%7C01%7Caharui%40adobe.com%7Ce0c38cc4559641ff0f2108d9d074405d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637770019992898481%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=c65JOYsEODcatlGZtwlpe7DOQanC%2BdL3zyGSPWgBYS4%3D&reserved=0> > > > > On Fri, 31 Dec 2021, 19:14 Maria Jose Esteve, <mjest...@iest.com> wrote: > > @Roman, which branch did you compile the SDK from, ROYALE_INTERFACE_INFO > or develop? > > Could you pass the Overview.mxml view to the main application? (to rule > it out) > > > > Hiedra > > > > *De:* Roman Isitua <romanisi...@gmail.com> > *Enviado el:* viernes, 31 de diciembre de 2021 17:56 > *Para:* users@royale.apache.org > *Asunto:* Re: Compiling Modules (was Re: Load time is very slow) > > > > I have tried tracing where the errors are happening whenever I test the > release version > > Uncaught TypeError: Ql.valuesImpl.init is not a function > at Hr.Cr.um (Overview.js:846) > at Function.ep.generateMXMLProperties (Overview.js:795) > at Hr.Sp.generateMXMLAttributes (Overview.js:599) > at new Hr (Overview.js:864) > at PN.M.loadHandler (FrontEnd.js:2042) > 9Overview.js:173 Uncaught TypeError: this.createElement is not a function > at $B.V (Overview.js:173) > at new $B (FrontEnd.js:2430) > at EP.convert (FrontEnd.js:2430) > at Zy (FrontEnd.js:261) > at HTMLAnchorElement.Uy (FrontEnd.js:121) > at HTMLAnchorElement.Sy.b (FrontEnd.js:117) > > > > > > The highlighted code in red is declared as follows in the Overview.mxml > (maven module) > > > > <j:valuesImpl> > > <js:SimpleCSSValuesImpl/> > > </j:valuesImpl> > > > > The j:valuesImpl points to the following code in jewel Module.js > > > > /** > * @nocollapse > * @export > * @type {org.apache.royale.core.IValuesImpl} > */ > org.apache.royale.jewel.Module.prototype.valuesImpl; > > > org.apache.royale.jewel.Module.prototype.set__valuesImpl = function(value) > { > org.apache.royale.core.ValuesManager.valuesImpl.init(this); > }; > > > > > > it appears this function is improperly renamed and whenever the app tries > to load the module is not able to recognise it as a function. > > > > The same issue of improper function renaming is happening in the second > error as well > > > > 9Overview.js:173 Uncaught TypeError: this.createElement is not a function > > > > > > On Thu, Dec 30, 2021 at 10:42 PM Roman Isitua <romanisi...@gmail.com> > wrote: > > > > I have applied the js compiler option as follows > > > > > <additionalCompilerOptions>-source-map=false;-compiler.show-binding-warnings=false;-js-default-initializers=true;-js-dynamic-access-unknown-members=true; > -js-compiler-option=--variable_map_output_file > gccvars.txt;-js-compiler-option+=--property_map_output_file gccprops.txt > </additionalCompilerOptions> > > > > > > I get the same error as before when attempting to launch the jewel module. > > > > *Error! Filename not specified.* > > > > > > Same error trace. > > > > Uncaught TypeError: cm.valuesImpl.init is not a function > at Rr.Mr.yl (Overview.js:786) > at Function.iq.generateMXMLProperties (Overview.js:736) > at Rr.hq.generateMXMLAttributes (Overview.js:546) > at new Rr (Overview.js:804) > at LN.J.loadHandler (FrontEnd.js:1967) > FrontEnd.js:1640 Uncaught TypeError: M is not a function > at oM.J.handleMouseOut (FrontEnd.js:1640) > at Function.ny [as googFireListener] (FrontEnd.js:123) > at ny (FrontEnd.js:248) > at HTMLAnchorElement.iy (FrontEnd.js:125) > at HTMLAnchorElement.b (FrontEnd.js:121) > FrontEnd.js:1640 Uncaught TypeError: M is not a function > at oM.J.handleMouseOver (FrontEnd.js:1640) > at Function.ny [as googFireListener] (FrontEnd.js:123) > at ny (FrontEnd.js:248) > at HTMLAnchorElement.iy (FrontEnd.js:125) > at HTMLAnchorElement.b (FrontEnd.js:121) > FrontEnd.js:1640 Uncaught TypeError: M is not a function > at oM.J.handleMouseOut (FrontEnd.js:1640) > at Function.ny [as googFireListener] (FrontEnd.js:123) > at ny (FrontEnd.js:248) > at HTMLAnchorElement.iy (FrontEnd.js:125) > at HTMLAnchorElement.b (FrontEnd.js:121) > FrontEnd.js:1640 Uncaught TypeError: M is not a function > at oM.J.handleMouseOver (FrontEnd.js:1640) > at Function.ny [as googFireListener] (FrontEnd.js:123) > at ny (FrontEnd.js:248) > at HTMLAnchorElement.iy (FrontEnd.js:125) > at HTMLAnchorElement.b (FrontEnd.js:121) > FrontEnd.js:1640 Uncaught TypeError: M is not a function > at oM.J.handleMouseOut (FrontEnd.js:1640) > at Function.ny [as googFireListener] (FrontEnd.js:123) > at ny (FrontEnd.js:248) > at HTMLAnchorElement.iy (FrontEnd.js:125) > at HTMLAnchorElement.b (FrontEnd.js:121) > FrontEnd.js:1640 Uncaught TypeError: M is not a function > at oM.J.handleMouseOver (FrontEnd.js:1640) > at Function.ny [as googFireListener] (FrontEnd.js:123) > at ny (FrontEnd.js:248) > at HTMLAnchorElement.iy (FrontEnd.js:125) > at HTMLAnchorElement.b (FrontEnd.js:121) > FrontEnd.js:1640 Uncaught TypeError: M is not a function > at oM.J.handleMouseOut (FrontEnd.js:1640) > at Function.ny [as googFireListener] (FrontEnd.js:123) > at ny (FrontEnd.js:248) > at HTMLAnchorElement.iy (FrontEnd.js:125) > at HTMLAnchorElement.b (FrontEnd.js:121) > 3Overview.js:56 Uncaught TypeError: Cannot read properties of undefined > (reading 'prototype') > at P (Overview.js:56) > at SG.convert (FrontEnd.js:904) > at ny (FrontEnd.js:248) > at HTMLElement.iy (FrontEnd.js:125) > at HTMLElement.b (FrontEnd.js:121) > > > > On Thu, Dec 30, 2021 at 6:56 PM Harbs <harbs.li...@gmail.com> wrote: > > 1. I’d get rid of the agressive minification options. It will likely cause > issues. If you get it to work without those options, you can try to add > them back in and see if it still works. > > 2. You seem to be missing the compiler options explained here: > https://apache.github.io/royale-docs/features/modules#minification > <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fapache.github.io%2Froyale-docs%2Ffeatures%2Fmodules%23minification&data=04%7C01%7Caharui%40adobe.com%7Ce0c38cc4559641ff0f2108d9d074405d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637770019992898481%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=y2M3Q%2F9KMsGdV2gANubdFhMj3uB5rzUgVxJDbF6wYKI%3D&reserved=0> > > > > For a pom, it would look something like this (adjust your paths to match > your setup): > > > > Main app: > > <additionalCompilerOptions>-source-map=true;-js-compiler-option=--variable_map_output_file > gccvars.txt;-js-compiler-option+=--property_map_output_file > gccprops.txt</additionalCompilerOptions> > > > > Module: > > <additionalCompilerOptions>-source-map=true;-js-compiler-option=--variable_map_input_file > ../../../../../MainApp/bin/js-release/gccvars.txt;-js-compiler-option+=--property_map_input_file > ../../../../../MainApp/bin/js-release/gccprops.txt</additionalCompilerOptions> > > > > On Dec 30, 2021, at 7:43 PM, Roman Isitua <romanisi...@gmail.com> wrote: > > > > I think it will be better for me to share my pom's that way you can see > all the compilation options used. The pom for the parent (FmClient2), the > MainApp and one module (Overview) have been attached to this email. > > > > > > On Thu, Dec 30, 2021 at 6:22 PM Harbs <harbs.li...@gmail.com> wrote: > > Roman, can you share your full compiler options? > > > > I decided to remove the below settings completely > -export-public-symbols=false > -prevent-rename-protected-symbols=false > -prevent-rename-public-symbols=false > -prevent-rename-internal-symbols=false > > > I enabled the below settings > > -js-dynamic-access-unknown-members=true; > -js-default-initializers=true > > > The release version starts up > > > > Hiedra, that’s great! > > > > On Dec 30, 2021, at 7:15 PM, Roman Isitua <romanisi...@gmail.com> wrote: > > > > > > Yes. I am testing with the sdk compiled on branch ROYALE_INTERFACE_INFO > > > > On Thu, Dec 30, 2021 at 6:10 PM Maria Jose Esteve <mjest...@iest.com> > wrote: > > Roman, are you testing with the SDK compiled from the Harb branches, > ROYALE_INTERFACE_INFO, or from develop? > > > > Hiedra > > > > *De:* Roman Isitua <romanisi...@gmail.com> > *Enviado el:* jueves, 30 de diciembre de 2021 16:52 > *Para:* users@royale.apache.org > *Asunto:* Re: Compiling Modules (was Re: Load time is very slow) > > > > I decided to remove the below settings completely > -export-public-symbols=false > -prevent-rename-protected-symbols=false > -prevent-rename-public-symbols=false > -prevent-rename-internal-symbols=false > > > I enabled the below settings > > -js-dynamic-access-unknown-members=true; > -js-default-initializers=true > > > The release version starts up > > > > > > > > <image001.png> > > > > > > <image002.png> > > > > However, the moment I launch a module. I get the below error > > > > <image003.png> > > > > > > It appears to be failing when I launch the "*Overview*" module > (by clicking the Overview side menu). > > > > So my current observation is that by retaining only two settings > > > > -js-dynamic-access-unknown-members=true; > -js-default-initializers=true > > > > The release module starts up but the app fails whenever I launch a module. > > > > The smallest size settings in the documentation do not work. The app does > not start up. > > > > -export-public-symbols=false > -prevent-rename-protected-symbols=false > -prevent-rename-public-symbols=false > -prevent-rename-internal-symbols=false > > > > > > > > The error trace is below > > > > > > Uncaught TypeError: cm.valuesImpl.init is not a function > at Wr.Rr.pl > <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwr.rr.pl%2F&data=04%7C01%7Caharui%40adobe.com%7Ce0c38cc4559641ff0f2108d9d074405d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637770019992898481%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=N4Mx5wcKqYMpOWlu5N7IbWeBmPyhbDkM0OAAnOqjZlI%3D&reserved=0> > (Overview.js:792) > at Function.mq.generateMXMLProperties (Overview.js:743) > at Wr.lq.generateMXMLAttributes (Overview.js:551) > at new Wr (Overview.js:810) > at QN.J.loadHandler (FrontEnd.js:1978) > 3Overview.js:56 Uncaught TypeError: Cannot read properties of undefined > (reading 'prototype') > at P (Overview.js:56) > at VG.convert (FrontEnd.js:910) > at ny (FrontEnd.js:250) > at HTMLElement.iy (FrontEnd.js:125) > at HTMLElement.b (FrontEnd.js:121) > FrontEnd.js:1649 Uncaught TypeError: M is not a function > at sM.J.handleMouseOut (FrontEnd.js:1649) > at Function.ny [as googFireListener] (FrontEnd.js:123) > at ny (FrontEnd.js:250) > at HTMLAnchorElement.iy (FrontEnd.js:125) > at HTMLAnchorElement.b (FrontEnd.js:121) > FrontEnd.js:1649 Uncaught TypeError: M is not a function > at sM.J.handleMouseOver (FrontEnd.js:1649) > at Function.ny [as googFireListener] (FrontEnd.js:123) > at ny (FrontEnd.js:250) > at HTMLAnchorElement.iy (FrontEnd.js:125) > at HTMLAnchorElement.b (FrontEnd.js:121) > J.handleMouseOver @ FrontEnd.js:1649 > ny @ FrontEnd.js:123 > ny @ FrontEnd.js:250 > iy @ FrontEnd.js:125 > b @ FrontEnd.js:121 > FrontEnd.js:1649 Uncaught TypeError: M is not a function > at sM.J.handleMouseOut (FrontEnd.js:1649) > at Function.ny [as googFireListener] (FrontEnd.js:123) > at ny (FrontEnd.js:250) > at HTMLAnchorElement.iy (FrontEnd.js:125) > at HTMLAnchorElement.b (FrontEnd.js:121) > J.handleMouseOut @ FrontEnd.js:1649 > ny @ FrontEnd.js:123 > ny @ FrontEnd.js:250 > iy @ FrontEnd.js:125 > b @ FrontEnd.js:121 > FrontEnd.js:1649 Uncaught TypeError: M is not a function > at sM.J.handleMouseOver (FrontEnd.js:1649) > at Function.ny [as googFireListener] (FrontEnd.js:123) > at ny (FrontEnd.js:250) > at HTMLAnchorElement.iy (FrontEnd.js:125) > at HTMLAnchorElement.b (FrontEnd.js:121) > J.handleMouseOver @ FrontEnd.js:1649 > ny @ FrontEnd.js:123 > ny @ FrontEnd.js:250 > iy @ FrontEnd.js:125 > b @ FrontEnd.js:121 > FrontEnd.js:1649 Uncaught TypeError: M is not a function > at sM.J.handleMouseOut (FrontEnd.js:1649) > at Function.ny [as googFireListener] (FrontEnd.js:123) > at ny (FrontEnd.js:250) > at HTMLAnchorElement.iy (FrontEnd.js:125) > at HTMLAnchorElement.b (FrontEnd.js:121) > J.handleMouseOut @ FrontEnd.js:1649 > ny @ FrontEnd.js:123 > ny @ FrontEnd.js:250 > iy @ FrontEnd.js:125 > b @ FrontEnd.js:121 > FrontEnd.js:1649 Uncaught TypeError: M is not a function > at sM.J.handleMouseOver (FrontEnd.js:1649) > at Function.ny [as googFireListener] (FrontEnd.js:123) > at ny (FrontEnd.js:250) > at HTMLAnchorElement.iy (FrontEnd.js:125) > at HTMLAnchorElement.b (FrontEnd.js:121) > J.handleMouseOver @ FrontEnd.js:1649 > ny @ FrontEnd.js:123 > ny @ FrontEnd.js:250 > iy @ FrontEnd.js:125 > b @ FrontEnd.js:121 > FrontEnd.js:1649 Uncaught TypeError: M is not a function > at sM.J.handleMouseOut (FrontEnd.js:1649) > at Function.ny [as googFireListener] (FrontEnd.js:123) > at ny (FrontEnd.js:250) > at HTMLAnchorElement.iy (FrontEnd.js:125) > at HTMLAnchorElement.b (FrontEnd.js:121) > J.handleMouseOut @ FrontEnd.js:1649 > ny @ FrontEnd.js:123 > ny @ FrontEnd.js:250 > iy @ FrontEnd.js:125 > b @ FrontEnd.js:121 > FrontEnd.js:1649 Uncaught TypeError: M is not a function > at sM.J.handleMouseOver (FrontEnd.js:1649) > at Function.ny [as googFireListener] (FrontEnd.js:123) > at ny (FrontEnd.js:250) > at HTMLAnchorElement.iy (FrontEnd.js:125) > at HTMLAnchorElement.b (FrontEnd.js:121) > J.handleMouseOver @ FrontEnd.js:1649 > ny @ FrontEnd.js:123 > ny @ FrontEnd.js:250 > iy @ FrontEnd.js:125 > b @ FrontEnd.js:121 > FrontEnd.js:1649 Uncaught TypeError: M is not a function > at sM.J.handleMouseOut (FrontEnd.js:1649) > at Function.ny [as googFireListener] (FrontEnd.js:123) > at ny (FrontEnd.js:250) > at HTMLAnchorElement.iy (FrontEnd.js:125) > at HTMLAnchorElement.b (FrontEnd.js:121) > J.handleMouseOut @ FrontEnd.js:1649 > ny @ FrontEnd.js:123 > ny @ FrontEnd.js:250 > iy @ FrontEnd.js:125 > b @ FrontEnd.js:121 > > > > On Thu, Dec 30, 2021 at 4:32 PM Roman Isitua <romanisi...@gmail.com> > wrote: > > I get the same error even when I set > the -js-dynamic-access-unknown-members=true; > > > > On Thu, Dec 30, 2021 at 4:24 PM Roman Isitua <romanisi...@gmail.com> > wrote: > > > > Using the below settings, > > -export-public-symbols=false > -prevent-rename-protected-symbols=false > -prevent-rename-public-symbols=false > -prevent-rename-internal-symbols=false > -js-dynamic-access-unknown-members=false; > > -js-default-initializers=true > > > Debug version runs fine. The release version does not start up > > <image004.png> > > > I get the below errors > > Uncaught TypeError: Cannot read properties of undefined (reading 'apply') > at KE.hm (FrontEnd.js:1600) > at XE.M.Fb (FrontEnd.js:943) > at XE.M.uh (FrontEnd.js:937) > at FE.M.na > <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Ffe.m.na%2F&data=04%7C01%7Caharui%40adobe.com%7Ce0c38cc4559641ff0f2108d9d074405d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637770019992898481%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=C0z70EcllmVEEFk21%2FuH%2FhC%2Fz8a8hrB7AuxRyMw%2FXn4%3D&reserved=0> > (FrontEnd.js:497) > at FE.M.v (FrontEnd.js:497) > at dR.M.S (FrontEnd.js:213) > at dR.Nz.S (FrontEnd.js:217) > at dR.M.start (FrontEnd.js:1396) > at index.html:45 > :8080/favicon.ico:1 Failed to load resource: the server responded with a > status of 404 (Not Found) > > > > > > FrontEnd.js is the start up class for the application. i.e. It implements > the Jewel application class. > > > > > > > > On Thu, Dec 30, 2021 at 3:19 PM Roman Isitua <romanisi...@gmail.com> > wrote: > > Hi Harb, > > > > Thanks for your response. I have gone through the documentation. I will do > my test again starting with the smallest size option and share my findings. > > > > Regards, > > > > On Thu, Dec 30, 2021 at 10:59 AM Harbs <harbs.li...@gmail.com> wrote: > > Sorry for my deal in responding. > > > > Let’s take a step back. > > > > I’m not sure how you are compiling your modules. I just added some content > to the module documentation page which explains what compiler options you > need while compiling modules. (It still needs some editing.) > https://apache.github.io/royale-docs/features/modules#minification > <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fapache.github.io%2Froyale-docs%2Ffeatures%2Fmodules%23minification&data=04%7C01%7Caharui%40adobe.com%7Ce0c38cc4559641ff0f2108d9d074405d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637770019992898481%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=y2M3Q%2F9KMsGdV2gANubdFhMj3uB5rzUgVxJDbF6wYKI%3D&reserved=0> > > > > Are you using those options? > > > > On Dec 29, 2021, at 2:19 AM, Maria Jose Esteve <mjest...@iest.com> wrote: > > > > Hi, Let me join you with these tests.... > > > > @Harb, I have compiled the SDK from this branch, > feature/ROYALE_INTERFACE_INFO, > and when running in debug I get this error: > > > > Message on the PURGE CONSOLE is displayed: > > > > Cannot convert org.apache.royale.reflection.beads.ClassAliasBead to IBead > > > > Message in the IDE Window: > > > > Se produjo una excepción: TypeError: Cannot convert [object Object] to > IBead > > at App.org.apache.royale.core.ElementWrapper.addBead ( > http://localhost:8080/WNetSuitePlus/org/apache/royale/core/ElementWrapper.js:114:11 > ) > > at App.org.apache.royale.core.HTMLElementWrapper.addBead ( > http://localhost:8080/WNetSuitePlus/org/apache/royale/core/HTMLElementWrapper.js:43:65 > ) > > at App.org.apache.royale.jewel.Application.start ( > http://localhost:8080/WNetSuitePlus/org/apache/royale/jewel/Application.js:246:10 > ) > > at App.App_loadXML (http://localhost:8080/WNetSuitePlus/App.js:1681:25 > ) > > at > org.apache.royale.net.URLLoader.org.apache.royale.events.EventDispatcher.fireListeners > ( > http://localhost:8080/WNetSuitePlus/org/apache/royale/events/EventDispatcher.js:97:23 > ) > > at Function.goog.events.EventTarget.dispatchEventInternal_ ( > http://localhost:8080/WNetSuitePlus/library/closure/goog/events/eventtarget.js:381:26 > ) > > at > org.apache.royale.net.URLLoader.org.apache.royale.events.EventDispatcher.dispatchEvent > ( > http://localhost:8080/WNetSuitePlus/org/apache/royale/events/EventDispatcher.js:72:37 > ) > > at org.apache.royale.net.URLLoader.jsEventHandler ( > http://localhost:8080/WNetSuitePlus/org/apache/royale/net/URLLoader.js:169:12 > ) > > > > Call stack: > > > > <image003.png> > > > > [INFO] Executing MXMLC in tool group Royale with args: [ > > > -load-config=D:\Develop_Royale\Projects\WinPlusWebSuite\royaleapp\royalelogin\target\compile-app-config.xml, > > -js-default-initializers=true, > > -source-map=true, > > -js-dynamic-access-unknown-members=true, > > > -keep-as3-metadata+=Inject,Dispatcher,EventHandler,Event,PostConstruct,PreDestroy,ViewAdded,ViewRemoved,Bindable,Transient, > > -keep-code-with-metadata=Inject, > > -show-binding-warnings=false, > > -export-public-symbols=false, > > -prevent-rename-protected-symbols=false, > > -prevent-rename-internal-symbols=false, > > > -js-output=D:\Develop_Royale\Projects\WinPlusWebSuite\royaleapp\royalelogin\target\javascript, > > -compiler.targets=JSRoyale, > > > D:\Develop_Royale\Projects\WinPlusWebSuite\royaleapp\royalelogin\src\main\royale\App.mxml > > > > > > The release execution does not change, the error is the same as before > (SDK compilation from the develop branch): > > > > Se produjo una excepción: ReferenceError: Error #1065: Variable > com.iest.winplusweb.models.MasterConfigSystemModel is not defined. > > at yR (http://localhost:8080/WPWebRelease/App.js:3605:1771) > > at Mya (http://localhost:8080/WPWebRelease/App.js:3343:365) > > at AR.J.usa (http://localhost:8080/WPWebRelease/App.js:434:441) > > at GFa.J.fromTypeDefinition ( > http://localhost:8080/WPWebRelease/App.js:5706:139) > > at Function.YT.getTypeDescriptor ( > http://localhost:8080/WPWebRelease/App.js:4570:820) > > at Function.fX.constructBean ( > http://localhost:8080/WPWebRelease/App.js:2336:472) > > at r$.J.initialize (http://localhost:8080/WPWebRelease/App.js:5041:66) > > at OW.J.init (http://localhost:8080/WPWebRelease/App.js:950:452) > > at OW.J.u (http://localhost:8080/WPWebRelease/App.js:951:454) > > at $$.J.addBead (http://localhost:8080/WPWebRelease/App.js:357:549) > > > > The main difference: > > project compiled from "SDK-develop" runs fine in js-debug and gives error > in js-release and, compiled from "SDK-ROYALE_INTERFACE_INFO" does not > launch because of conversion error. > > > > Hiedra > > > > *De:* Roman Isitua <romanisi...@gmail.com> > *Enviado el:* martes, 28 de diciembre de 2021 15:55 > *Para:* users@royale.apache.org > *Asunto:* Re: Load time is very slow > > > > @Harb > > > > I have checked out the feature/ROYALE_INTERFACE_INFO branch and compiled > asjs and compiler. I have rebuilt my application with modules in release > mode. > > > > I get the following error when I attempt to launch a module > > > > > > <image001.png> > > > > > > The module loads fine in debug mode > > > > <image002.png> > > > > > > Snippets of the log > > > > Overview.js:786 Uncaught TypeError: cm.valuesImpl.init is not a function > at Rr.Mr.yl (Overview.js:786) > at Function.iq.generateMXMLProperties (Overview.js:736) > at Rr.hq.generateMXMLAttributes (Overview.js:546) > at new Rr (Overview.js:804) > at LN.J.loadHandler (FrontEnd.js:1967) > Mr.yl @ Overview.js:786 > iq.generateMXMLProperties @ Overview.js:736 > hq.generateMXMLAttributes @ Overview.js:546 > Rr @ Overview.js:804 > J.loadHandler @ FrontEnd.js:1967 > load (async) > LN.loadModule @ FrontEnd.js:1965 > dN.loadModule @ FrontEnd.js:2406 > LD.Un @ FrontEnd.js:1809 > ny @ FrontEnd.js:123 > ny @ FrontEnd.js:248 > iy @ FrontEnd.js:125 > b @ FrontEnd.js:121 > > > > > > I have attached the full log to this email. > > > > > > > > > > On Tue, Dec 28, 2021 at 2:51 PM Roman Isitua <romanisi...@gmail.com> > wrote: > > Hi Maria, > > > > Prior to starting this mail discussion "Load time is very slow". I can > confirm I have only been compiling in debug mode. My target\javascript\bin\ > only had js-debug. It was after I upgraded my royale sdk from 0.9.7 to > 0.9.8 that I compiled in release mode. > > > > > > > > On Tue, Dec 28, 2021 at 2:24 PM Maria Jose Esteve <mjest...@iest.com> > wrote: > > Hi, @Roman, I think you are doing a double compile can it be? My times are > the same as yours and I always compile in debug and release. > > > > Look at your target folder " target\javascript\bin\" and if you have two > folders: js-debug and js-release you are compiling always double. > > > > In my case, the architecture of my project as well as the Maven > compilation files (pom.xml) were provided by an external company (we didn't > know anything about Maven or Royale at that time) and I understand that > this formula was chosen to show us the options we had. > > > > A priori and without doing any test as Harb has done, I think that > modularity gives us the advantage of compiling parts of the code once and > not compiling them again if they are not modified. So far WITH MY > COMPILATION TIMES, sometimes more than 1 minute, this is fundamental. But > of course, now we have the problem of minification of the modules and it is > really a serious problem because it is impossible for us to deploy in > production. > > > > I will try to separate the compiación realese with a profile and if I > succeed I will pass it to you @Roman. > > > > @Harb what do you mean by compiling the ROYALE_INTERFACE_INFO branch? > > > > Hiedra > > > > *De:* Harbs <harbs.li...@gmail.com> > *Enviado el:* lunes, 27 de diciembre de 2021 18:32 > *Para:* users@royale.apache.org > *Asunto:* Re: Load time is very slow > > > > That doesn’t sound right. > > > > Are you sure you’re compiling debug and not release? That sounds like > release build times. > > > > On Dec 27, 2021, at 3:31 PM, Roman Isitua <romanisi...@gmail.com> wrote: > > > > Wow ! You are using a workstation with a bleeding edge processor. > > > > I just compiled my app now. It took 44 seconds. (First compilation after > ide start up.) Subsequently compilations are usually 19s to 20s. > > > > My application code base is very very small compared to yours. As we > continue to add functionality, I expect the compile times to rise. > > > > > > > > > > <MainApp_pom.xml><Overview_pom.xml><fm_client2_pom.xml> > > > >